W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Re: SHOULD use POST for expensive queries?

From: Pat Hayes <phayes@ihmc.us>
Date: Wed, 18 Jan 2006 16:37:23 -0600
Message-Id: <p06230914bff47352eda5@[]>
To: Kendall Clark <kendall@monkeyfist.com>
Cc: dawg mailing list <public-rdf-dawg@w3.org>

>Mark Baker suggests [1] that we should add a SHOULD requirement that 
>queryHttpPost binding should be used "where the cost of processing 
>the query may be prohibitive". I don't really agree with this, since 
>there's no way to no statically which are the expensive and which 
>are the cheap queries. Even very sophisticated query analysis can't 
>tell you which RDF datasets are expensive to assemble.
>And, further, I don't know of any way to programmatically redirect 
>expensive GETs to POSTs (you can send a Location: header to the POST 
>endpoint, if it's different from the GET endpoint, but I don't think 
>that *really* suffices; alternately, we could define a WSDL fault, 
>UsePost, but that seems an awful kludge), and I don't really see the 
>*point* of doing so either, since if the query is too expensive, 
>it's too expensive, whether it comes in via GET or POST.
>Mark retorts [2] that the "safety" of GET includes expensive 
>operations, citing some message from Roy Fielding, but I think the 
>message undercuts Mark's use of it, since it's very clearly about 
>implementations of services, not about the semantics of their 
>Pat +1'd the proposal, but that was before further discussion,


>so I'm not certain where he would be now.

I withdraw the +1. I apparently misunderstood what the proposal entailed.


>I'm opposed to the inclusion that Baker suggests, for the reasons 
>I've stated, but I will leave it to the WG to decide.
>Kendall Clark

IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Wednesday, 18 January 2006 22:37:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:50 UTC