Re: JSON headers

--------
In message <F72E21BA-E891-4E1B-8535-385616431390@lukasa.co.uk>, Cory Benfield w
rites:

>> 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.
>
>This is one of those interesting decisions that has a tendency to make 
>life very tricky for implementation authors. Generally speaking it is 
>unwise to have the 'do nothing' behaviour be totally 
>wrong: that's arguably what this would do. Specifically, if you 
>write a HTTP implementation and don't know anything about the 
>Content-Encoding header, in the current model you shouldn't be 
>served anything weird.

Remember, I'm talking about a new HTTP version here, with a different
and closely shaved semantic layer.

In that version, I would argue that "anything weird" includes
uncompressed data.

If the client sends HTTP/1.1, then the server knows the semantics are
"dot-one" and "anything weird" is compression.

If the client sends HTTP/1.2 *and* the server replies with HTTP/1.2
as well, then they *both* know that "anything weird" is uncompressed.

>(I should also note that it's weird that all Accept-Encoding 
>header lists are implicitly terminated with 'identity', 
>but the absence of such a header translates into 'gzip'. 
>That's a strange inconsistency and I guarantee it'll 
>trip people up. It's only an inconsistency though, and your 
>rationale for it is well-reasoned.)

It was meant as a strawman to show how much improvement could be had,
not as a final proposal :-)

-- 
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 Saturday, 9 July 2016 20:46:13 UTC