W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: updated http 1.1 rfcs and hop-by-hop

From: Martijn Faassen <faassen@startifact.com>
Date: Mon, 18 Aug 2014 10:39:01 +0200
Message-ID: <CAGT4ZFjt__Ct2n06gWJ5A2yLU0ZjTkSR19JG02PJ0W4SzRr=nQ@mail.gmail.com>
To: ietf-http-wg@w3.org
Hi there,

No answer to my question at all so far? Perhaps it's the wrong list?
Any feedback would be appreciated!

Thank you!

Martijn


On Mon, Aug 11, 2014 at 4:42 PM, Martijn Faassen <faassen@startifact.com> wrote:
> Hi there,
>
> [I hope this question reaches the right mailing list]
>
> I'm trying to find the equivalent of RFC 2616, section 13.5.1 in the
> new specs. This section defines those header fields considered
> hop-by-hop, i.e.:
>
>       - Connection
>       - Keep-Alive
>       - Proxy-Authenticate
>       - Proxy-Authorization
>       - TE
>       - Trailers
>       - Transfer-Encoding
>       - Upgrade
>
> I need such a list in order to implement a Python WSGI-based proxy.
> See PEP 3333:
>
> http://legacy.python.org/dev/peps/pep-3333/#other-http-features
>
>   However, because WSGI servers and applications do not communicate
> via HTTP, what
>   RFC 2616 calls "hop-by-hop" headers do not apply to WSGI internal
> communications.
>   WSGI applications must not generate any "hop-by-hop" headers [4],
> attempt to use
>   HTTP features that would require them to generate such headers, or
> rely on the content
>   of any incoming "hop-by-hop" headers in the environ dictionary. WSGI
> servers must
>   handle any supported inbound "hop-by-hop" headers on their own, such
> as by decoding
>   any inbound Transfer-Encoding, including chunked encoding if applicable.
>
> So, a WSGI proxy has to remove any hop-by-hop headers from the
> response of the host it is proxying, and not pass them along. WSGI has
> its own iterator based mechanism to support chunking, and a WSGI
> server can then add the appropriate headers.
>
> In section 13.5.1 of RFC 2616 these hop-by-hop headers are specified,
> but I can't find the equivalent in the newer RFCs.
>
> I do find section 6.1 in rfc7230, so I think this means that a
> conforming server would list related headers in the Connection. But
> what about Transfer-Encoding, for instance? A server that sends
> "Connection: close" may not send Transfer-Encoding?
>
> It's certainly possible that I'm missing something. I haven't read the
> complete specs yet. But any guidance would be appreciated.
>
> Regards,
>
> Martijn
Received on Monday, 18 August 2014 08:39:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC