- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 20 Aug 2014 07:06:37 -0700
- To: Martijn Faassen <faassen@startifact.com>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
On Aug 19, 2014, at 3:35 AM, Martijn Faassen wrote: > Hey, > > Thanks, this is helping my comprehension. I've written up a blog post > describing the relation between the new HTTP 1.1 RFCs and Python WSGI > spec here: > > http://blog.startifact.com/posts/new-http-rfcs-versus-wsgi.html > > Hopefully I didn't get it too wrong. I'll bring up this post to the > Python web special interest group too. Transfer-Encoding is not listed in Connection because removing it without decoding the message body would be a severe error. The notion that certain header fields are "hop-by-hop" in RFC2616 was poorly considered. Fields are always forwarded unless there exists a specific requirement to delete them in transit, where each such requirement effectively depends on the conformance and version of the recipient. Hence, the Connection header field has a specific requirement to delete the listed fields and itself. Transfer-Encoding does not have a specific requirement regarding deletion of the field, but does require that its value correspond to the transfer codings that are applied to the message body. Hence, when one or more of those codings is decoded, the sender must adjust the Transfer-Encoding field accordingly. ....Roy
Received on Wednesday, 20 August 2014 14:07:06 UTC