 |
 |
Hi Ralph - At Tue, 1 Jun 2010 15:17:02 -0400, LeVan,Ralph wrote: > A simple use case comes from OpenSearch and its use of URL > templates. To enable the return of RSS as the response to an SRU > query, we added the parameter "httpAccept=application/rss+xml" to > the SRU URL in the OpenSearch template and coded for it in the SRU > server. Had we had a filter in the request, the servlet's life would > have been easier. > > That seemed like a specific solution to what could be a > generalizable problem. There have been long discussions on the rest-discuss mailing list about this issue. (See, e.g, [1].) Frankly I think that it is wrong to think of your httpAccept param as equivalent to an HTTP header. There is a time for a URI that can use content-negotiation (the Accept header, etc.) to get, e.g., PDF, HTML, or plain text. As an example: http://example.org/RFC1 And there is a time when we want to explicitly refer to a particular resource that has only ONE type. For example, the canonical version of an RFC: http://example.org/RFC1.txt But these are different resources. If you want to be able to link to search results that must be returned in RSS, a query parameter or file extension is proper. But this query param or file extension, in my opinion, is quite different than HTTP content negotiation or the Accept header. At Tue, 1 Jun 2010 15:36:23 -0400, Joe Hourcle wrote: > > On Tue, 1 Jun 2010, Erik Hetzner wrote: > > 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) Not the solution I would prefer for debugging, but if it is not exposed to the outside world, OK. > 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 Yes, with caveats above. > > 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. I don’t assume, I know a 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) As far as I know there are only 2 solutions, a 301 response and Content-Location [2]. Either one works fine. This is not a contentious issue, it is just one that a lot of web sites do not handle properly. I’m not sure what FRBR has to do with it. I think the web architecture documents have good, practical things to say about what is identified by a URI. best, Erik Hetzner 1. http://tech.groups.yahoo.com/group/rest-discuss/message/11508 2. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.14