2616: Testing "MUST ignore" in section 14.10

Hi,

	RFC 2616, section 14.10 "Connection" has two similar MUSTs,
one for all messages and one specifically for HTTP/1.0 messages:

   HTTP/1.1 proxies MUST parse the Connection header field [...]  and,
   for each connection-token in this field, remove any header field(s)
   from the message with the same name as the connection-token.

and

   A system receiving an HTTP/1.0 (or lower-version) message that
   includes a Connection header MUST, for each connection-token in this
   field, remove and ignore any header field(s) from the message with
   the same name as the connection-token.
	
As you can see, the only real difference between the two requirements
is that for HTTP/1.0 messages, matching headers must not only be
removed, but also _ignored_.  Testing the "remove" part is easy. I am
trying to come up with a good case for HTTP/1.1 proxies that tests the
"ignore" part.

The short version of my question is: "Can anybody come up with a
real-world case or at least a sane example, where the ``and ignore''
part of the lower requirement would matter?" On other words, can one
auto-detect that the proxy is not ignoring the headers it removes?

For details, please read on.


So, I want to construct an HTTP/1.0 message with a header that, if not
ignored by the proxy, will cause some auto-detectable or traceable
action. Ideally, I need to do that for both requests and responses.
This is a black-box testing.

I cannot find any good headers that test the "ignore part". I assume
that the original message was generated by an HTTP/1.1-aware agent and
forwarder via an HTTP/1.0 proxy that does not understand Connection:
and uses HTTP/1.0 message version. Connection: header field MUST NOT
contain end-to-end headers, so I want to use hop-by-hop headers and
extension headers when forming the test message. Moreover, any sane
proxy will ignore any extension header so true hop-by-hop headers are
the only ones left. They are:

      - Connection
      - Keep-Alive
      - Proxy-Authenticate
      - Proxy-Authorization
      - TE
      - Trailers
      - Transfer-Encoding
      - Upgrade

Furthermore, I need a header that is not supported by HTTP/1.0 proxies
and that requires some detectable action from an HTTP/1.1 proxy.
Authentication headers are very cumbersome to test with. Remaining
headers are:

	- Connection
	- Transfer-Encoding

"Connection: Connection" is obviously not useful in this context.

"Connection: Transfer-Encoding" is not good either because if HTTP/1.0
proxy ignored (and hence forwarded) Transfer-Encoding, things are
already pretty broken, and the HTTP/1.1 proxy should probably notice
Transfer-Encoding and react in some way other than ignoring it!

Thus, I am tempted to conclude that no remotely possible real-world
scenario would produce a combination of headers where violating the "and
ignore" part of the RFC requirement would break things more than
honoring that requirement.

Can anybody confirm or provide a good example where honoring the
"and ignore" requirement would be detectable?


Thank you,

Alex.

P.S. I can build a test case by putting end-to-end headers such as
     Vary or Cache-Control into a Connection field, but that is quite
     unrealistic and violates HTTP/1.1.

Received on Monday, 17 June 2002 12:55:33 UTC