Re: [RFC] Optional header negotitation

On Friday 17 August 2007, Robert Brewer wrote:
> How is that sequence of events any better than:
>
>  * User-agent always sends the extension-header "Timezone"
>  * Server takes advantage of the "Timezone" header
>    whenever it's present
>
> ? HTTP already has an "extension-header" token in the grammar,
> for pete's sake. Since both parties need to know about any
> extension header to take advantage of it, where's the benefit
> of explicitly asking for it? Just send it every time.

'extension-header' was a poorly chosen phrase. I didn't new it existed in 
RFC2626, but it seems that is matches :-)

Anyway, just ignore the 'extension-header' in that phrase, or remove the dash.

> > It seems to me that web based
> > applications can really use additional HTTP headers but
> > we cannot propose them because of the extra overhead
> > they will introduce (like the HTTP Timezone Header).
>
> Propose them all you want. If they're universally useful,
> then all servers and user-agents will adopt them and accept
> any overhead. If they're only useful to some servers and
> user-agents, then only those parties should pay the price
> of extension. The overhead of an extra request header field

The facts regarding this are:

a) I already proposed that and the feedback I got indicated that there is 
concern about the additional overhead it will introduce.

b) The 'universally useful' does not seem to apply to 'Timezone' (even though 
I strongly believe that it is) and I'm sure that other headers won't be. 
That's why I'm proposing an on-demand approach, to eliminate the 'universally 
useful' requirement for additional HTTP headers. After all it is not wise to 
say: "It seems that a part of web scripts could benefit from the 'Timezone' 
header. Lets send it to everyone, just to be sure."

  I'm also considering the possibility that this method will be used by *both* 
ends to request additional headers. For example, if we could travel back in 
time and perform some changes, clients could be able to request the 'Server' 
and 'Date' headers on demand.

> of extension. The overhead of an extra request header field
> for a small set of cooperating parties is far smaller than
> the overhead of two extra messages for all parties whether
> they use optional features or not.

  The way I'm thinking of (and proposing) it will result in no overhead for 
parties that don't support it. Server side support will be implemented by 
scripts and not by servers and thus those scripts will actually need this. 
Client side browsers that don't support this will not need to change anything 
and there will be no overhead. Browsers that support it will have the option 
to perform an additional request with the extra header included. Then they 
will need to cache this information for at least the current session and keep 
sending this header to the server without additional overhead. For an 
additional request to happen, both client and server sides need to support it 
and the server side needs to ask for an additional header. I find 
this 'overhead' extremely small compared to current 'Location:' header usage 
and I believe that it is the smallest possible.

  Finally, I don't understand what you mean when saying: 'two extra messages 
for all parties'.

Received on Saturday, 18 August 2007 11:13:17 UTC