On Tue, 1 Jun 2010, Erik Hetzner wrote:
> At Tue, 1 Jun 2010 14:21:56 -0400, LeVan,Ralph wrote:
>>
>> I've been sensing a flaw in HTTP for some time now.  It seems like you
>> ought to be able to do everything through a URL that you can using a
>> complete interface to HTTP.  Specifically, I'd love to be able to
>> specify values for HTTP headers in a URL.


> I am having a hard time imagining the use case for this.
>
> Why should you allow a link to determine things like the User-Agent
> header? HTTP headers are set by the client for a reason.

I can think of a few cases -- debugging is the most obvious, but possibly 
also to work around cases where someone's browser is sending a header 
that's screwing something up.  (which is basically debugging, as I'd have 
the user try a few things, and then once I knew what was going wrong, I'd 
fix it so we didn't have to have workarounds)

But all of the cases that I can think of where it'd be useful, there's 
already work arounds --

 	Cache-Control : add a random query string
 	Accept (if using content negotiation) : add a file extension
 	Accept-Language : add a language extension


> Furthermore, as somebody involved in web archiving, I would like to
> ask you not to do this.
>
> It is already hard enough for us to tell that:

[trimmed]

You'll always have those problems when assuming that URL is a good 
identifier.

The only good solution would be for webservers to respond back with a sort 
of 'preferred URI' with the response -- some do it via redirection, but 
you're never going to get everyone to agree -- and in the example above 
with the various 'Accept' headers, you have the question about what it is 
that you're trying to identify (the general concept, the specific 
translation, or the translation + packaging? ... and then we get into FRBR 
territory)

-Joe