RE: Making Implicit C-E work.

On 01 May 2014 01:29, adrien@qbik.com wrote:
> ...
> Why mess with C-E or any entity headers?  What about another way of
> effectively doing T-E, but that doesn't need to be computed each time.
> Like Message-Encoding or something but which can be cached by the O-S or
> edge server or proxy or whatever, and it retains the original entity headers.

We suggested exactly that a few weeks ago, but didn't get much response (see draft RFC in [2]).


> ...Maybe that is just T-E.

You're right. It's really similar, but suggesting T-E out loud is liking saying Voldemort around here :)


BTW, in another thread Mark said: "As Chair, I get very concerned when people try to make HTTP/2 a trojan horse for "improving" a particular situation, because the experience with new features layered into HTTP/1.1 this way (e.g., expect/continue, pipelining) was poor, and also because we'll be on a slippery slope to having lots of other people throw in their hobby features too." [1]

Why should implicit C-E get an exception?

We've got some ideas for fixing http performance and interop too :)
e.g. end-to-end Message-Encoding [2]; unambiguous range requests (w.r.t. content coding); etc.

[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1098.html
[2] https://github.com/shearl/Internet-Drafts/blob/master/draft-morgan-http-message-encoding/draft-morgan-http-message-encoding.txt

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Thursday, 1 May 2014 22:01:33 UTC