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

On 19/08/2014 8:35 p.m., Martijn Faassen wrote:
> Hi there,
> 
> I'm not sure I'm getting it yet. Does this mean that servers should be
> sending out a Connection header that looks
> like this?
> 
> Connection: close, Transfer-Encoding
> 
> Instead of just:
> 
> Connection: close
> 
> Or is 'Transfer-Encoding' a hopX-by-hopY behavior (I don't understand
> what this is)?

Transfer-Encoding has the hopX-to-hopY behaviour.

The server just emits Transfer-Encoding. A proxy receiving it is allowed
to strip away the header and payload encoding, but it is also allowed to
just relay both through - provided the receiving client is also HTTP/1.1
and can handle the decoding.

The Proxy-Auth* headers are the same. Get sent by whichever hop needs to
auth and stripped by whichever receiving hop requested authentication.


hopX-by-hopY (of hopX-to-hopY) is how I describe a setup like this:
 client-> proxy -> X -> proxy -> proxy -> Y -> proxy -> server

If X and Y are both negotiating the use of features between themselves
and over the proxies between. hop-by-hop and end-to-end being the well
known extreme/special cases of the general X-to-Y situation.


> 
> I'm having trouble finding where the RFC currently specifies that a
> particular header, such as Transfer-Encoding, should be in a
> 'Connection' entry.

The TE header is one with mandatory Connection:TE. You can see that
"MUST" in the final paragraph of section 4.3:
"  sender of TE MUST also send a "TE" connection option within the
   Connection header field
"

The Upgrade header is another. You can see that "MUST" in the
4th-to-last paragraph of section 6.7:
"  sender MUST also send a Connection header
   field (Section 6.1) that contains an "upgrade" connection option
"

The Connection header itself is hop-by-hop, its "MUST" is in paragraph 2
of section 6.1:
"  A proxy or gateway MUST parse a received Connection header field
...
   then remove the Connection header field itself
   (or replace it with the intermediary's own connection options for the
   forwarded message).
"

HTH
Amos

Received on Tuesday, 19 August 2014 09:18:41 UTC