Re: [RFC] Optional header negotitation

On Tuesday 21 August 2007, Robert Brewer wrote:
> Stefanos Harhalakis wrote:
>
> On Tuesday 21 August 2007, Robert Brewer wrote:
> > > Different clients use different means to determine when to
> > > send 'additional' headers:
> > >
> > >  * wget provides the user a '--header' command-line argument.
> > >  * Atom Publishing Protocol clients may send a "Name" request
> > >  * Most modern browsers allow servers to send them javascript.
> > >  * Some applications allow users to fully script the HTTP
> >
> > Do you actually believe that having a standard way to do
> > these things will not be a benefit? Why not propose a
> > standard to fit those needs?
>
> Yes, I actually believe that. You can't codify/systematize the
> whole world, and in fact attempting to do so leads to fragile,
> stale societies. Let the applications which use HTTP decide
> how best to coordinate additional headers in a way that is
> best suited to each one of them.

1) What aspect of the proposal would lead to something being 'fragile' or 
becoming 'stale'?
2) As I said previously, this will be just a method. If it is usefull then ok, 
if it is not then no-problem.
3) Can you be more specific? What you mean by saying 'coordinate'? Are you 
aware of something like this?

> Or, you could ask yourself why none of the above applications
> (and in fact, I know of no applications which) send a second
> message asking for more headers, when they could easily do so
> today without an additional standard.

  I find this sentence non-consistent with the rest of our talking. Let me 
summarize:

Once you said: 
> I don't
> think that changes my central reservation: that HTTP
> already allows enough ways to ask for extended headers
> that there's no need to canonicalize one of those ways.

(You said 'ASK')

you also said:
> Every previous HTTP app which has needed additional
> headers seems to have done just fine without a formal
> "Header-Request" response header.

I asked:
> Can you please provide me with additional information
> about how apps are doing this?

You provided the examples:
>  * wget provides the user a '--header' command-line argument.
>  * Atom Publishing Protocol clients may send a "Name" request
>  * Most modern browsers allow servers to send them javascript.
>  * Some applications allow users to fully script the HTTP

(where: 'wget' does not 'ask for extended headers', I already said that I 
don't see javascript as a solution and I'm not familiar with how Atom 
works...)

And now you're saying that those are *NOT* asking for 'extended headers'? That 
takes us back 3 messages, where I asked:

> Can you please provide me with additional information
> about how apps are doing this?

.......

  I believe there is a missunderstanding somewhere. I'm not against 
applications using their own custom headers. But web browsers are not just 
clients for a specific application, and thus they will almost never 
send 'custom' headers, unless something like a plugin is loaded and it sends 
its own headers (everywhere?), so the only method to provide additional 
headers is by sending them all of the time (no?)

  Let me describe the proposal once more, being less abstract: Provide a way 
for server side scripts to optionally request one or more optional additional 
headers from browsers. If browsers support those headers then they may 
optionally include them in their future HTTP requests.

  I still don't understand why you're claiming that this is bad. Your main 
reasoning is that server side scripts MUST NOT have a standard that they will 
be able to optionally follow. If I understand your thoughts correctly, then 
why don't you object for HTTP Authentication which is similar? What about 
Accept-Language? Both of them could be handled without a standard by 
applications. What about 'Location'? 

  Finally I'd really like to listen to at least another one's opinion about 
this, just to find out whether I am (or not) the one that missunderstands 
something...

p.s. I'm not familiar with the rules of the list. Should we continue this 
conversation in private and post a summary of it, or we should keep posting 
at the list? (I'm in favour of posting to the list since it will allow for 
others to observe and will be available for future reference)

Received on Tuesday, 21 August 2007 16:43:36 UTC