- From: Jacek Kopecky <jacek.kopecky@sti2.at>
- Date: Mon, 17 Aug 2009 13:26:10 +0200
- To: Gregory Williams <greg@evilfunhouse.com>
- Cc: Steve Harris <steve.harris@garlik.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
Hi Greg, there is no reason that the content returned by OPTIONS should not also be accessible by GET elsewhere; the HTTP header Content-Location would help here. In this way, OPTIONS on the service endpoint would be a clear machine-oriented way of discovering service descriptions; for human-oriented ways, a link from the endpoint's documentation or query form (with conneg for HTML) or whatever should be good. What do you think? Jacek On Tue, 2009-08-11 at 02:08 -0400, Gregory Williams wrote: > On Aug 11, 2009, at 2:01 AM, Steve Harris wrote: > > > On 11 Aug 2009, at 06:03, Gregory Williams wrote: > > > >> I'm still worried about HTTP OPTIONS not having a lot of support in > >> some client libraries. It also (I believe) make it difficult to get > >> at a service description with a web browser for visual inspection. > >> Do any browsers provide a way to make OPTIONS requests (I know curl > >> allows this)? > > > > Certainly Firefox and Safari do. I don't have any others to test on, > > but a quick google suggests that IE and Chrome support it too. See http://www.w3.org/TR/XMLHttpRequest/ > > Hmmm... I was hoping for something that didn't involve javascript > (hence "visual inspection"). I'd like to be able to glance over what's > in a service description without having to resort to programming. I > suppose the conneg option might help here, but in general I suspect > conneg for html would return just a query form, not an html-formatted > version of the service description. > > .greg > >
Received on Monday, 17 August 2009 14:11:06 UTC