RE: [search-ws] ResponseType parm and Accept header are equivalent (and some implications of that)

["LeVan,Ralph" <levan@oclc.org>]

I would never have guessed that ‘$’ was a legal character in a URL.  I have no problem with that suggestion, but take some exception to the phrase “distinguishes them from SRU specific query parameters”.  These are definitely SRU specific parameters.  They are not parameters commonly accepted in other URLs.  Nor are they parameters specific to SRU queries.

 

But, $accept does help reflect the more global implication of the parm.

 

Ralph

 

From: Houghton,Andrew
Sent: Thursday, January 22, 2009 11:36 AM
To: Ray Denenberg, Library of Congress; LeVan,Ralph; search-ws@lists.oasis-open.org
Cc: Young,Jeff (OR)
Subject: RE: [search-ws] ResponseType parm and Accept header are equivalent (and some implications of that)

 

My only suggestion here would be consider prefixing these types of content negotiation query parameter with something that distinguishes them from SRU specific query parameters.  For example use $accept, $accept-charset, $accept-language, $accept-encoding, etc.  There are also additional implications in regard to HTTP status codes and responses.  If someone adds $accept=application/rss+xml to the SRU query parameters and the SRU server only supports Atom, application/atom+xml, then the SRU server should respond with HTTP 406 Not Acceptable.

 

Andy.

 

From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: Thursday, January 22, 2009 11:00 AM
To: LeVan,Ralph; search-ws@lists.oasis-open.org
Cc: Young,Jeff (OR); Houghton,Andrew
Subject: Re: [search-ws] ResponseType parm and Accept header are equivalent (and some implications of that)

 

I finally got around to this as well as the earlier message, sorry for the delay.

 

 I agree with Ralph (to the extent that I understand it).

 

Thanks Ralph.

 

--Ray

----- Original Message -----

From: LeVan,Ralph

To: search-ws@lists.oasis-open.org

Cc: Young,Jeff (OR) ; Houghton,Andrew

Sent: Monday, January 19, 2009 2:59 PM

Subject: [search-ws] 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