[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] ResponseType parm and Accept header are equivalent (and some implications of that)
Thanks Andy and Jeff; I'm sure nobody was offended. I think we're just trying to figure out whether it's a good idea to distinguish a class of SRU parameters in the manner suggested, and my initial thought is that it is a good idea. We need to kick it around a bit. --Ray ----- Original Message ----- From: "Houghton,Andrew" <houghtoa@oclc.org> To: "Young,Jeff (OR)" <jyoung@oclc.org>; "LeVan,Ralph" <levan@oclc.org>; "Ray Denenberg, Library of Congress" <rden@loc.gov>; <search-ws@lists.oasis-open.org> Sent: Thursday, January 22, 2009 12:12 PM Subject: RE: [search-ws] ResponseType parm and Accept header are equivalent (and some implications of that) Jeff got the intent of my message exactly correct. I apologize about the wording of my message I should probably not been so terse and I didn't mean to offend or upset anybody. Andy. > -----Original Message----- > From: Young,Jeff (OR) > Sent: Thursday, January 22, 2009 12:08 PM > To: LeVan,Ralph; Houghton,Andrew; 'Ray Denenberg, Library of Congress'; > 'search-ws@lists.oasis-open.org' > Subject: RE: [search-ws] ResponseType parm and Accept header are > equivalent (and some implications of that) > > I could be wrong, but I assume that Andy is suggesting that the '$' > indicates information that normally would be obtained from HTTP > headers. The labels, then should presumably match those headers. Even > though this is a novel idea, it is easily and usefully generalized > beyond SRU. > > Jeff > > > -----Original Message----- > > From: LeVan,Ralph > > Sent: Thursday, January 22, 2009 11:43 AM > > To: Houghton,Andrew; 'Ray Denenberg, Library of Congress'; '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) > > > > 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 <mailto:levan@oclc.org> > > > > To: search-ws@lists.oasis-open.org > > > > Cc: Young,Jeff (OR) <mailto:jyoung@oclc.org> ; Houghton,Andrew > > <mailto:houghtoa@oclc.org> > > > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]