Re: JSON headers

[Phil Hunt <[e-mail]>]

Not sure if this has been discussed. One of the biggest problems with HTTP request signing has been repeat headers. It presents problem of detecting which headers are intended and which header was signed first.

It would be nice if the JSON encoding handled arrays so that the demand for duplicate headers is removed.  Signing could then be more successful and could even stipulate that the presence of a repeat header in a signed request is a failure condition.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[e-mail] <mailto:[e-mail]>





> On Jul 8, 2016, at 10:49 AM, Poul-Henning Kamp <[e-mail]> wrote:
> 
> Since Marks call for adoption of this draft, I've been thinking a lot about the
> general topic.
> 
> There is no doubt that the current way we've been doing HTTP headers has turned
> into a bit of a boondongle.
> 
> Switching to a consistent structured format is certainly a good idea, and as
> such formats go, JSON is far from the worst one could pick.
> 
> So, yes, in principle I'm all for this.
> 
> However, and you knew that would be coming, I have three major issues with this.
> 
> Future binary format
> --------------------
> 
> I really hope we are going to discontinue the text-processing
> approach to the HTTP protocol headers required for transport purposes.
> 
> Sending numbers, and particular dates as ascii strings is simply
> not sensible with speeds north of 10 Gb/sec.
> 
> If we decide to standardise on _a_ structured format, we should pick
> one that has a high-performance-sensible binary parallel, which
> can be used in HTTP/2 and onwards
> 
> I know about BSON, BJSON and CBOR, there are probably other as well,
> we need to study them carefully so we do not paint ourselves into
> a corner here.  The binary versions limitations/encodings in a high
> performance setting may affect how we use/constrain usage of the
> textual version.
> 
> How do we specify this in RFCs
> ------------------------------
> 
> This is the BIG one.
> 
> Julians draft does not addrss this at all:  We need a "ABNF" for
> specifying the structured syntax of standard headers.
> 
> Before we open the floodgates for JSON (or whatever) headers,
> we absolutely have to have found and nailed down how they will
> be documented/specified in RFCs.
> 
> This syntax specification has to be both human- and machine-readable,
> so known-to-be-compliant efficient code can be generated directly
> from the RFC text.
> 
> There's something called "JSON-schema"
> 
> 	http://json-schema.org/example1.html
> 
> It doesn't look apetizing to me, see for instance their
> JSON-schema for JSON-schema-JSONs:
> 
> 	http://json-schema.org/schema
> 
> Being able to piggy-back on something like that would be a big
> plus over rolling our own.
> 
> 
> Simplify semantics
> ------------------
> 
> I realize that Julians draft specifically targets newly defined
> headers, and that is a good starting point.
> 
> However, we should leverage this to re/bis-define standard headers
> in the new format too so they can have their semantics reduced and
> simplified with a venegance.
> 
> To take Accept-encoding as an example:
> 
> It should be constrained to a simple list in order of preference,
> with identity being the implicit last element.  Not on the list?
> not accepted.
> 
> Forget the bloody useless q= values, forget sending it in any order
> you happen to like, forget sending multiple headers.
> 
> 	Accept-Encoding: [ "gzip", "deflate" ]
> 
> There, done.
> 
> Do we even need both gzip and deflate ?  No, of course we do not.
> 
> Other more competent compressions ?  Yes by all means, but the same
> compression with/without some trivial header-bytes is just a stupid
> waste of everybodys time and code.
> 
> Even better:
> 
> 	Accept-Encoding: [ "gzip" ]
> 
> Now lets go one step further:  Most implementations today support
> gzip, so the above should be the default if no Accept-Encoding
> header is present.  If you do not support gzip, you'll have to
> send:
> 
> 	Accept-Encoding: [ ]
> 
> Everybody else can avoid sending Accept-Encoding entirely.
> 
> We can repurpose the minor number of HTTP protocol numbers
> to indicate the sematic version:
> 
> 	HTTP/1.0 -> ascii headers we know and have a complex 
> 		    and unfulfilling relationship with
> 	HTTP/1.1 -> the bugfix release
> 
> 	HTTP/2.0 -> HPACK'ed ascii headers
> 	HTTP/2.1 -> future bugfix release
> 
> 	HTTP/1.2 -> Ascii JSON headers
> 	HTTP/2.2 -> Binary JSON headers
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> [e-mail]         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.
>