[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ResponseType parm and Accept header are equivalent (and some implications of that)
I claim that our new responseType parameter is equivalent to
an HTTP Accept header. The purpose of the parameter is to allow the
client to be able to specify the mime type of the response. (As a
provocative aside, I further claim that current SRU servers could deliver non-SRU
responses to SRU requests today on the basis of Accept headers. All we’re
doing in our standards work is agreeing on how to express that Accept header in
our URLs.) I propose that we change the name of the responseType
parameter to “accept”. There is no reason for us to invent a
new name for something that has well-understood semantics. (My co-workers
suspect that there are other HTTP headers that we may also want to represent in
our URLs, but we’ll leave them for the day when we have a real use case.) I’ve been discussing this topic with some of my
co-workers and there are some implications of this recognition that our
parameter is an alternative to an Accept header. I believe our current documentation says that the mime-type
of an SRU response is text/xml. We need to change that to application/x-sru+xml
and need to start the process of registering our mime-type with IANA so we can
get rid of the x- part. If an SRU server supports multiple mime types and uses
content negotiation to determine the mime-type of the response, then the server
should proved a URL in the Content-Location header of the response pointing
directly to the response in that mime-type. For instance, if the client
had sent the URL http://example.org/sru?query=dog
with an Accept header of “application/rss+xml”, then the server
should return a Content-Location value of http://example.org/sru?query=dog&accept=application/rss+xml.
This Content-Header is returned along with the content itself, presumably in
the application/rss+xml format. It would also be acceptable to have
returned a redirect to that URL instead, but that behavior is not encouraged as
it is inefficient. Even in the absence of an Accept header, this behavior
becomes important. If there was no Accept header or an Accept header of “*”
and a URL of http://example.org/sru?query=dog,
our standard says that the response should be of the mime-type
application/x-sru+xml. That means that there was, in fact, content
negotiation going on and a Content-Location header of http://example.org/sru?query=dog&accept=application/x-sru+xml
should be returned with the response. I believe that this behavior needs to be documented as part
of the change to accept the accept parameter. Ralph |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]