Subject: TE header

From: Joe Orton <[email-masked]>
Date: Sat, 3 Aug 2002 10:58:30 +0100

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?

Regards,

joe

---

From: Alex Rousskov <[email-masked]>
Date: Sat, 3 Aug 2002 09:06:17 -0600 (MDT)

Joe,

	The MUST clause wording is clearly buggy. The clause should
either be deleted or reworded to specify a different reason.

	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!

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 5 Aug 2002 13:01:05 -0600 (MDT)

On Mon, 5 Aug 2002, Jeffrey Mogul wrote:

> Joe Orton writes:
> Alex Rousskov writes:
> No, the MUST clause is correct.  Consider this scenario:
> 
> HTTP/1.1 client sends this request to RFC2068-compliant proxy:

I have to disagree. Yes, the _result_ of the clause is correct. No,
the explanation offered in the clause seems incorrect. The explanation
says that TE must be supplied because it is a hop-by-hop header.
That's misleading because hop-by-hop headers are already handled
correctly without Connection: stuff. What it should probably say is
that TE must be supplied because 2068 compliant proxies do not know
about TE hop-by-hop header. That is, the reason for this MUST is
compatibility with earlier RFCs.

Do you see what I am getting at? An average implementor will probably
pause for a seconds and say "hmm, compliant proxies already support
hop-by-hop headers so I can ignore this MUST".

With your explanation/example, it is clear that MUST directions 
are valid. It's just that the motivation seems to be missing or is
misleading.

> 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.

Yes, of course. This is more suitable for "known HTTP
[implementations] problems draft" and does not call for RFC changes.

Thank you,

Alex.

---

From: Jeffrey Mogul <[email-masked]>
Date: Mon, 5 Aug 2002 14:50:30 -0400 (EDT)

Joe Orton writes:

    

Alex Rousskov writes:

	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:

	    Connection: close, TE

-Jeff