Re: Headers / caches proposal (revised)

Maciej,

On 5/3/06, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On May 3, 2006, at 5:19 PM, Mark Baker wrote:
>
> > On 5/2/06, Maciej Stachowiak <mjs@apple.com> wrote:
> >> BTW, I don't think "only appended to" solves it, since one of the
> >> anticipated problems is that "Close" could be added and may break an
> >> existing persistent connection.
> >
> > If by "break" you mean "close cleanly", sure.  But there's little harm
> > in that in general, since UAs already have to know to start new
> > connections if one fails (and another isn't available from the
> > pool). And I would think that being able to close connections could
> > be useful
> > in some cases.
>
> I'm not sure network libraries will all react gracefully to a
> "Connection: close" they did not add themselves.

I can't think of a reason why they wouldn't; as I say above, they
already have to accomodate connections which drop for a multitude of
reasons.

> > Alternately, if folks feel strongly about this, we could prevent
> > "close" from being added to the Connection header.
>
> That would end up with disallowing "close" and also any header field
> that the XMLHttpRequest client may not set at all, or may only append
> to (since we would not want to allow clients to force the proxy to
> remove the UA-set value).

Sorry Maciej, I don't understand what you mean there.

> That would be much more complicated than
> the restrictions on any other header field, which are either "you
> can't set it at all" or "you can only add to but not replace the UA
> value". Is being able to set "Connection" a sufficiently compelling
> use case to warrant this additional complexity?

Well, it prevents any future hop-by-hop extension headers from being
used.  Since we can't know what kind of extensions might be defined in
the future though, it's impossible to know exactly what it'll cost us
today.  But it is a fairly broad chunk of HTTP
functionality/extensibility to make inaccessible.

> Note that we did not
> choose to do this for other headers where some values might be valid
> and interesting but others might be problematic. "Connection" does
> not seem obviously more useful than "Accept-Encoding" for instance.

I think it is, because while we don't expect XHR apps to manage
content codings (that "layer" is hidden from them), the scope of
Connection isn't limited low layer functionality.

Mark.

Received on Thursday, 4 May 2006 16:41:22 UTC