JSON headers

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"


It doesn't look apetizing to me, see for instance their
JSON-schema for JSON-schema-JSONs:


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

	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
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Friday, 8 July 2016 17:49:39 UTC