Outstanding Issues / Comments for HTTP/Update
ISSUE-56: Does HTTP PATCH affect either the SPARQL Protocol or the SPARQL Uniform etc. HTTP etc. Protocol?
This is related to the outstanding comment on the same issue:
the [...] text seems to imply that a PATCH request would contain SPARQL Update command(s) in the body of the request but doesn't say so specifically [...] What is the WG's thinking/intentions with regards to PATCH, will it become normative in later drafts of the specification and is it intended as a mechanism to allow SPARQL Update to be made using the protocol?
I'm (personally) inclined to leave the behavior or PATCH as informative and (admittedly) vague. If that behavior is to be specified any more precisely, then issues about how UPDATE requests that target more than one graph, etc. would need to be spelled out and resolved and it seems to me that 'opening the door' in that way should be sufficient to implementors who want to support invoking SPARQL Update via PATCH with little ambiguity as to behavior if the the various HTTP protocols are leveraged.
However, given the fact that we have a formal comment on the issue, we probably should bring it up for conversation as an agenda item.
ISSUE-63: Handling of default graph in HTTP update protocol
See Andy's description of the problem and suggested resolution:
In implementing http-rdf-update, I need to also address the default graph of a graph store, for POST and GET [...] At one level, this (the use of ?default) is an extension to http-rdf-update because http-rdf-update does not cover addressing the default graph of a graph store, but at the same time, it would be good for implementations to do the same thing.
Resolving this, however, introduces a (more substantive) dependency on the issue below (since a network-manipulable graph store needs to also include the default graph).
The ?default syntax seems reasonable to me (once the issue below has been resolved)
(No formal issue): Network-manipulable Graph Store needs to include default graph
Within Andy's email above:
"Network-manipulable Graph Store" excludes the default graph but I don't see an rationale for this. If it had been just a collection of graphs, not a graph store, then the absence of an un-named one is explicable, but the document directly discusses graph stores and whether a URI identifies the underlying network-manipulable Graph Store.
Changing the definition of the Network-manipulable Graph store should straightforwardly address the problem but some thought needs to be put into the impact the addressability of the default graph (a key principle of REST).
(No formal issue): Confusion regarding recommended behavior of OPTION method
Also, in Andy's email above:
This confused me. Earlier, the text used the URI as the graph store, not the service (description). We seem to have update and/or query service at the same place as the graph store. This would be OK, as services are split by HTTP query string, but not if the graph store is GETtable and there is a service description to return.
For http-rdf-update, I'd suggest it's the graph store (RDF dataset) that is on the web. The service model is more appropriate for SPARQL Update language and query.
Personally, I'm inclined (only by a little) to not have the query/update services and the graph store be the same resource. However, this would either require a naming convention otherwise (as one possible solution) the request URI for request that use the ?graph (or ?default) query strings would have to identify the service and the URI of the graph store would be provided in the response to a request to the service via the OPTIONSs method (as a service description).
I think it would help to have this conversation within the WG as a proper agenda item to solicit other opinions.
(Comment): No content-type on payload
Kjetil's suggestion about responding with 400 will be incorporated into the editor's draft and a subsequent response can be sent to him upon LC publication
(Comment): HTTP DELETE operation
Kjetil suggested that the specification should explicitly say that DELETE requests require the existence of the resource it is addressing, so a 404 needs to be returned. He also suggests that an indication that a 204 response can be returned should also be added to this section. Both changes will be added to the editor's draft, then a subsequent response can be sent after the next round of publications.
(Comment): Proper escaping of URIs and payload on update operations
See KK-4 comment.
Unfortunately, I don't quite understand how the protocol (as described) is less vulnerable than any HTTP-based protocol. Section 4.2 (Indirect Graph Identification) does already discuss percent-encoding of embedded graph URIs and since the interface does not facilitate protocol tunneling, I don't see how requests to the modifying METHOD would be vulnerable in this way. Perhaps, some additional eyes in the WG could clarify the issue is and how it can be addressed.
(Comment):What to do if no payload
See KK-5 comment.
Section 5 says:
For requests that use HTTP verbs not listed here or for which the syntax of the request is not defined in this protocol, the server SHOULD respond with 405 (Method Not Allowed) or 400 (Bad Request), respectively.
This IMO adequately informs the developer about how to respond to POST / PUT requests with no payload since they would be malformed WRT the behavior of those methods as described in the protocol.