RE: [RFC] Optional header negotitation

Stefanos Harhalakis wrote:
On Monday 20 August 2007, Robert Brewer wrote:
> > Every previous HTTP app which has needed additional
> > headers seems to have done just fine without a formal
> > "Header-Request" response header. So I'd find an extra
> > RFC on the matter just as spurious, serving only to
> > complicate web app framework and user agent code
> > unnecessarily.
> 
> Can you please provide me with additional information
> about how apps are doing this? As far as I see it,
> javascript is not an option and I'm not aware of
> another method...

Different clients use different means to determine when to
send 'additional' headers:

 * wget provides the user a '--header' command-line argument.
   This puts the burden on the interactive user to decide
   which headers to send (in addition to those required by
   the HTTP spec).
 * Atom Publishing Protocol clients may send a "Name" request
   header in a POST to suggest a name for the POSTed resource.
   Similar mechanisms are used by other protocols such as WebDAV.
   This puts the burden on the authors and implementors of those
   specifications.
 * Most modern browsers allow servers to send them javascript.
   This puts the burden on the server, in the document workflow.
 * Some applications allow users to fully script the HTTP
   conversation. For example, Firefox's nsIhttpChannel, or
   Greasemonkey. This puts the burden on (the scripts of)
   the user.

Not that any of that would change if a "Header-Request" header
started to be widely used. What *would* happen is that all of
the maintainers of the above clients would come under pressure
from naive users to add more code for special-casing the receipt
of a "Header-Request" header. Server authors/maintainers, too.
I can just see Request objects the world over growing a new
"req.requested_headers" attribute so that they can...populate
those headers with the same values they were writing before,
using application-specific conventions and mechanisms. I just
don't see the benefit to generalizing the declaration, since
the above applications seem to be doing just fine without it.


Robert Brewer
fumanchu@amor.org