Re: JSON headers

[Mark Nottingham <[e-mail]>]

Catching up with a pile of post-holiday e-mail...

> On 9 Jul 2016, at 3: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.

Good. To be clear, in the lead-up to adoption, we said that this draft would be a starting point, and the approach *could* change dramatically, based upon discussion (and hopefully, running code and experimentation).



> 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.

Personally, I have always assumed that one of the major goals of such a convention would be enabling such an encoding in the future (probably in HTTP/n, since it's a backwards-incompatible change, although we might be able to do something in /2).


> 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.

I agree with the identified need (VERY much; again, one of the big goals for me here is to minimise the need for "advice" like we documented in 7231 8.3.1), but I'm not so sure about JSON Schema (as others have noted). No doubt we'll get into this.


> 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

Yet again personally, I was thinking we might want to introduce a set of alternative JSON headers to the most common ones, and allow some form of negotiation for their use. Perhaps j-accept-encoding, j-user-agent and so on.

Introducing minor version numbers to HTTP has proven to cause a lot of confusion; that's the main reason we got rid of minor version numbers in HTTP with /2. 

Cheers,



--
Mark Nottingham   https://www.mnot.net/