Re: HTTPbis -10 drafts published : Connection header

On Fri, Jul 16, 2010 at 01:08:39PM +0800, Thomson, Martin wrote:
> > > Yes, but why is that a problem?  First, the process adding headers
> > > should have already removed the Connection header received -- otherwise
> > > it isn't doing its job.  Second, even without fixing that bug, the
> > > result is fail safe -- the proxy won't be able to forward what it
> > > generated.
> >
> > It's not a problem from an HTTP point of view, the request is valid. It's
> 
> I don't see why you are belabouring the point.  Especially when it is predicated on a software error.
> 
> If the client wants a header to go to the origin server, don't use Connection.  If a proxy wants to ensure a particular header is set in a particular way, set that header.

I have no problem with that, but while it's easy to read it that way
once you got trapped, you should at least admit that it's not easy
to guess such side effects when blindly applying the spec :

   The "Connection" general-header field allows the sender to specify
   options that are desired for that particular connection and MUST NOT
   be communicated by proxies over further connections.
   ...
   HTTP/1.1 proxies MUST parse the Connection header field before a
   message is forwarded and, for each connection-token in this field,
   remove any header field(s) from the message with the same name as the
   connection-token.

So if the proxy decides to force a header to be set despite this header
being listed in Connection, it looks like it violates the spec.

As long as we'll have unclear situations where implementers have to
chose between strictly respecting the spec or doing the right thing,
we'll get such implementation issues. Of course these issues can be
fixed afterwards, but don't you think that the spec's purpose is also
not to direct implementers in the wrong direction ?

Also :

   Message headers listed in the Connection header MUST NOT include end-
   to-end headers, such as Cache-Control.

Almost all headers are supposed to be end-to-end. In fact, the hop-by-hop
ones are the ones enumerated in this header. If a client lists Content-Length
in Connection, does that make it a hop-by-hop header ? And if so, how should
a proxy proceed ? It's sort of an egg-and-chicken game. We're saying the proxy
"hey, I'm sending you a header I want you to remove, and since it's listed in
my Connection header, you are supposed to believe me and there is no risk that
the request you forward is not valid".

Maybe a single sentence could be added to clarify all things :

    HTTP/1.1 proxies MUST parse the Connection header field before a
    message is forwarded and, for each connection-token in this field,
    remove any header field(s) from the message with the same name as the
-   connection-token.
+   connection-token, unless that header was set by the proxy itself, eg.
+   for logging purposes or message integrity.

> Yes, you can probably screw up all sorts of things by doing all sorts of dumb things.  It's pointless compromising the integrity of a perfectly sound specification so that you can club a few idiots over the head with it.  That's a self-defeating principle - the idiots will simply find another dumb thing to do that you couldn't predict.

I'm amazed by the number of times I read that implementers are idiots or
stupid. If you tell them to implement vague things they will all do stupid
things. The people who define the spec have a very clear understanding of
its semantics, so there are a lot of obvious things to them. Implementers
have to learn these semantics by reading the spec. If the spec is unclear
or self-contradictory, you'll get as many incompatible implementations as
you have readers. From my understing, the goal of this WG is to spot unclear
areas which can lead to wrong implementations and to clear them. When we
find wrong implementations which can be explained by how the spec is read,
I think we should at least wonder if there is no other way to explain the
rules and make them more explicit.

> Your solution here is to submit a bug report.

That's what I intend to do, but the authors will have the right to
say "hey we've strictly followed the spec".

Willy

Received on Friday, 16 July 2010 06:35:42 UTC