RE: [RFC] Optional header negotitation

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

Well, now you know it's there. So use it. ;)

> 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."

No problem. As the designer of application-specific extension
headers, that decision is up to you.

> 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:

 * a server that wants a Timezone header can, today, send an
   entity header in the response like "Header-Request: Timezone",
   and clients that understand "Header-Request: Timezone"
   can respond, or...
 * servers can define their own "Timezone-Request" header
   to do the same thing, or...
 * Timezone-aware user-agents can send the "Timezone" header
   everywhere, or...
 * only to a preselected set of servers, or...
 * response bodies could contain code (e.g. javascript) to add
   a "Timezone" header to requests for specific URLs, or ...
 * the user-agent could provide a means for the user to decide
   whether to send the "Timezone" header, or...
 * clients can send a "Header-Request: Date" entity header
   in the request, or...
 * a million other ways of organizing the flow.

But that can all be done without formalizing a new "Header-Request"
into the spec, because the spec already allows for header
extension in a generic fashion.

> 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.
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.


Robert Brewer
fumanchu@aminus.org