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




> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
> On Behalf Of Paul Gearon
> Sent: 29 July 2009 19:05
> To: public-rdf-dawg@w3.org
> Subject: [ISSUE-32] Implications of updates on protocol, regarding HTTP
> methods
> 
> This email discharges my action
> http://www.w3.org/2009/sparql/track/actions/55

> 
> 
> The initial SPARQL language and protocol (SPARQL/Query 1.0,
> SPARQL/Protocol 1.0) both describe read-only operations, which left no
> change of state on the server. SPARQL/Update is expected to use the
> SPARQL/Protocol as well, however it is designed to modify state on the
> server, which in turn has implications for the protocol.

Expected? The expectation from SQL is SELECT and INSERT?DELETE go down the same connection does create a user perception but that's also the source of injection attacks.

Option 1 does not make that assumption.
 
...
> 
> Options for modifying the existing protocol for SPARQL/Update:
> 
> Option 1: Write an unrelated new protocol for the HTTP binding
> SPARQL/Update to operate on.
> This would appear to be duplicating some work, and still needs to
> address how modifying operations need to be called.

It has the advantage that different security can be applied at the HTTP level to the different endpoints.  It also can help avoid confusion resulting on the same endpoint between update and query operations causing injection attacks on the query endpoint.

What work is duplicated?  Sure there is some but my experience with Joseki is that it is very little and it wasn't designed with update in mind originally.

In Joseki, the same code routes query and update requests on different endpoints with the sole difference that update operations direct the request, after associating with the datasets, to an update processor, not a query processor.  The HTTP POST handling is the same.

> 
> Option 2: All modifying operations go through POST.
> While not mandated, the standard use of POST is to provide all data in
> the body. This is how the query operation works.

Just clarity - it's a WWW-encoded form, so the body is "query=...."

> This may inconvenient
> for applications that may want to execute a simple operation that can
> be encapsulated in the URI.
> 
> Option 3: All modifying operations go through PUT with a fallback to
> POST for large commands.
> This is similar to the definition of query which uses GET and POST.
> However, this is awkward if doing a PUT or a POST for a command that
> is trying to delete resources, such as triples or graphs, as the
> expected semantics of these methods is to add data to a server. Also,
> PUT is more tightly defined than POST, expecting a resource in the
> URI, while a different resource MUST be referred to with a different
> URI.
> 
> Option 4: Use appropriate methods for each action.
> This means using PUT to create resources, DELETE to remove them, GET
> and HEAD to query them. However, this is what the REST protocol will
> be doing, and makes the notion of a SPARQL/Update language
> superfluous.
> 
> 
> Option 2 appears to offer the least difficulty. Are other options available?

Options 1 and 2 (different endpoint, same endpoint) are both possible if we ensure an update can't look like a query.  Given that POSTing a query is still "query=" in the body, it's possible to do that.  But I think we should decide one of the other.

 Andy

> 
> Regards,
> Paul Gearon
> 
> [1] http://www.w3.org/TR/rdf-sparql-protocol/#query-bindings-soap

> [2] http://www.w3.org/TR/rdf-sparql-protocol/#query-bindings-http

> [3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1

Received on Wednesday, 29 July 2009 20:11:14 UTC