On 05/12/12 12:22, Claude Warren wrote:
I have a system that does conneg and returns different bodies for
SELECT statements, we don't support UPDATE but if we did I suspect
that we would also return different bodies in that case.
Slightly different case - Fuseki does conneg for query and for query
there is a definite answer (result set or graph).
In the update case, the request is a POST and there isn't a defined
response content.
Simon asked about setting it on the request and the query path already
has code to do that. Adding conneg to Fuseki for update is easy (use
the code from query!).
So mechanism is doable - the question remains what is being conneg'ed
for. The current implementation is to return 200 and an HTML page
saying "Success" if it was an HTML form sent; if it was
aplication/sparq-update, it responds with 204 (No Content i.e. empty
response body).
Andy
On Wed, Dec 5, 2012 at 11:52 AM, Andy Seaborne <[email protected]> wrote:
On 03/12/12 12:44, Simon Gábor wrote:
Hi All,
According to the SPARQL Update protocol recommendation:
"The response body of a successful update request is implementation
defined. Implementations *may* use HTTP content negotiation to provide
both
human-readable and machine-processable information about the completed
update request."
How can i specify accept header in the SPARQL Update request? I cannot
find
a way in UpdateProcessor (UpdateProcessRemote) or in UpdateRequest.
Simon,
There currently isn't a way to do that and also the .execute() operation
does not return anything. Errors appear as exceptions driven from the HTTP
response code.
What had you in mind?
I don't know of any systems currently that return different entity bodies
based on conneg. Are there any?
The reason in the spec for "MAY" is that there is no standard format for a
reply. RDFa, RDF, JSON [1] (why have an RDF processor when you send a
string?) all make sense in different scenarios.
Andy
[1] http://tools.ietf.org/html/draft-nottingham-http-problem-01
