Re: TE header

Joe Orton writes:

    I'm confused by this paragraph in section 14.39 of 2616:
    
       The TE header field only applies to the immediate connection.
       Therefore, the keyword MUST be supplied within a Connection header
       field (section 14.10) whenever TE is present in an HTTP/1.1 message.
    
    Since TE is already defined as hop-by-hop in section 13.5.1, it implies
    that any hop-by-hop headers used MUST be supplied in a Connection
    header, which is incorrect.
    
    Why is there a MUST that TE specifically is included in a Connection
    header? Is it really for compatibility with RFC2068-compliant proxies,
    which don't know that TE is hop-by-hop?

Alex Rousskov writes:

    The MUST clause wording is clearly buggy. The clause should
    either be deleted or reworded to specify a different reason.
    
No, the MUST clause is correct.  Consider this scenario:

HTTP/1.1 client sends this request to RFC2068-compliant proxy:

	GET http://example.com/foo.html
	Host: example.com
	TE: trailers

The RFC2068-compliant proxy doesn't know about TE (it wasn't
defined in RFC2068!) so it forwards the message to example.com.

If the MUST clause wasn't there, example.com would believe that
the proxy would accept trailer fields.  This is wrong, because
RFC2068 doesn't include trailers.  So the server-to-proxy response
message would be misinterpreted.

If the client follows the MUST in 14.39, then the proxy (which
*does* know about the Connection header, we had that in RFC2068)
will correctly strip the TE field from the request before forwarding
it to the origin server, and nothing goes wrong.

There might be other scenarios where the MUST is also required,
but this is the first one that I could think of.  Are there
RFC2068-compliant proxies out there?  Probably.

Alex Rousskov also  writes:

    FWIW, in our compliance tests, we saw only one HTTP proxy
    obeying this MUST and sending
    
	    Connection: close, TE
    
    when forwarding chunked messages. On the other hand, the same proxy
    was forwarding TE header passed to it, violating another, far more
    important MUST!

OK, I guess the proxy implementors of the world have some work
left to do!  We're not going to rewrite the spec to legalize
something bogus just because implementors aren't paying attention.

-Jeff

Received on Tuesday, 6 August 2002 04:20:44 UTC