Re: [RFC] Optional header negotitation

On Saturday 18 August 2007, Robert Brewer wrote:
> > 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.
>
> Again, no problem. My point is that that can all be handled
> already by any cooperating servers and clients, and the
> existing 'extension-header' is the way to do that:
>
>    "The extension-header mechanism allows additional entity-header
>     fields to be defined *without changing the protocol* ..."
>
> Without changing the protocol:
>
[...]
>  * Timezone-aware user-agents can send the "Timezone" header
>    everywhere, or...

  That's the main reason I got negative feedback on the original proposal.  
You suggest that I should consider this as a non-issue?

>  * only to a preselected set of servers, or...

  I don't consider this an option since I believe that will not be implemented 
at all.

>  * response bodies could contain code (e.g. javascript) to add
>    a "Timezone" header to requests for specific URLs, or ...

  There are cases where no javascript or any other *script languages are 
available.

> > Finally, I don't understand what you mean when saying:
> > 'two extra messages for all parties'.
>
> It's not critical to the point above. I was just pointing out
> that your example required four messages when both parties
> are Timezone-aware. There are other ways to structure the
> flow so that no additional messages are needed. The beautiful
> thing about the existing, generic extension-header mechanism
> is that my application is free to be designed that way,
> and yours is free to use more messages if you want them.

  Yes, but the clients need to send the extra header everywhere. This includes 
cases where this is not usefull (static content, most images, etc...). And 
the idea is that this proposal will not be specific to Timezone. Perhaps one 
day we would like to send our location/country for customized content, or... 
who knows...

  The 4 messages you're saying are in fact one extra request (2 messages) that 
will be performed only once at each session and only when both server side 
and client support and want to exchange that header. Apart from that, if one 
day the XXX (for example, Timezone) header becomes a commonplace, clients 
will be free to send it always (without waiting for a Header-Request). I'm 
not willing to suggest a restriction on that.

> But those are workflow-level concerns (and solutions),
> not protocol-level. So no change to the spec needed, and
> indeed, changing the spec to add a new "Header-Request"
> header would limit some of that freedom by canonicalizing
> a single optional-header workflow (and a poor one,
> but that can be argued elsewhere) when there's a benefit
> to allowing many.

  I see now that there are two meanings of the word 'optional':
* One that means that is optional for the protocol
* One that means that is optional for the content (and of course the protocol 
too)

I'm talking about the second case while you're refering to the first one. 
There is no indention at all to restrict HTTP! Just to provide a way for 
extending it with headers that aren't required everywhere. Of course other 
optional headers (as in the 1st case) will be able to be added.

p.s. Do you find this reply meaningfull or there is something you said that I 
didn't understand?

Received on Saturday, 18 August 2007 18:44:54 UTC