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
Sent from my free software system <http://fsf.org/>.
|
