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