Re: [ISSUE-32] Implications of updates on protocol, regarding HTTP methods

On 29 Jul 2009, at 20:48, Paul Gearon wrote:
>> I personally feel that it would be a serious mistake to encourage
>> SPARQL/Query requests to be sent as POST requests, it confuses  
>> caches (a
>> selling point of SPARQL in enterprise environments) and gives a false
>> impression of the scope of a SPARQL/Query operation.
>
> This refers back to the original SPARQL/Protocol, which has already
> defined this behavior. It may be poor practice, but it's in the spec,
> and I doubt there is the desire to change this. Looking at when to use
> GET vs POST [1], then I'd like to see SPARQL/Query all done as GET,
> and SPARQL/Update done as POST. But I don't get to change
> SPARQL/Query, so I'm trying to work around it.

Well, the original spec is worded pretty strongly, so I think we're  
covered there. It seems clear to me that it's only OK to use POST if  
the client or server doesn't have an adequate GET implementation.

> As for GET requests that are too long, I'd prefer to see GET with a
> message body. HTTP 1.1 does not prohibit this, though it is not common
> practice. There aren't many conversations around it, but [2] seemed to
> cover some of the issues.

There are HTTP servers that can't handle arbitrary GET parameters, but  
can handle GET with a body? That seems a bit of an odd implementation  
priority.

The only client I've encountered that has GET length limitations is  
XMLHTTPRequest in IE6, which I think is limited to 4kb. I've not  
really used a huge number though.

For the record, we regularly issue 50+kb SPARQL GET queries using  
libcurl/fopen() from PHP, and whatever's available in Perl. There  
seems to be a widely held opinion that GET is often length limited,  
but I don't think that's been true for a long time.

- Steve

Received on Wednesday, 29 July 2009 22:34:21 UTC