RE: JSON headers

Poul, let me attempt to recast what you're saying:  Structured headers good, binary structured headers better, and let's majorly rev the protocol to make sensible use of them everywhere.  I'm on the same page with you of liking structure, but needing some ABNF++ that can express a valid header format.  I also lament that we lost the binary header support during HPACK development.

Retconning the minor version number as a semantic version number is... intriguing.  The conclusion I reached while writing my draft on the semantic vs. mapping layer was fundamentally that we didn't change the semantic layer in HTTP/2, and consequently don't really have a versioning scheme for it right now.  Thanks for proposing one.  Unfortunately, it fundamentally breaks the promise we just restated in RFC 7230:  "The interpretation of a header field does not change between minor versions of the same major HTTP version, though the default behavior of a recipient in the absence of such a field can change."  I don't really want to go down that painful interoperability path.

You have, both here and in the past, described a number of potential changes for when/if we decide the rev the semantic layer.  That's a really interesting direction, and one I'm hoping we get to explore in the Workshop.  It's also currently outside this WG's charter and well beyond the question of whether we should adopt this draft.

Personally, I'll join in the support for structured header fields for the future.  Whatever it is, it should be easy to specify, easy to validate, and ideally human-readable.  I do support the adoption of a draft to move future headers in that direction.  I'm not convinced JSON is the right format for it, mostly for layering's sake, but I don't have a better candidate and we'll probably need a dedicated parser for whatever we end up with anyway.

-----Original Message-----
From: Poul-Henning Kamp [mailto:phk@phk.freebsd.dk] 
Sent: Friday, July 8, 2016 10:49 AM
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: 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"

	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
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 21:29:57 UTC