RE: [RFC] Optional header negotitation

Stefanos Harhalakis wrote:
> Example: A client contacts a web server and sends a GET
> request. Server side script (SC) is able to take advantage
> of header (H) (example: Timezone information) to adjust
> its content. SC examines the headers and finds out that
> the client did not send that header. Server side script
> sends an extra header like:
> 
> Header-Request: Timezone
> 
> and goes on sending the content. Client side browser:
> a) Does not support "Header-Request" and ignores it,
> rendering the page
> b) Supports Header-Request and the 'Timezone' optional
> header and resubmits a GET request with the optional
> header included (It would act as a refresh).

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.

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


Robert Brewer
fumanchu@aminus.org