Hi Simon,
What a nuisance. It's not, as far as I know, illegal, but it is a
rather odd interpretation of HTTP POST for remote operations.
Not sending "Accept" is because it's a POST which does not need to
return anything. conneg for an HTML page is find but it's not conneg if
it returns it without being asked for! I'm a bit worried that changing
in the general casefor Dydra means it will be inconvenient elsewhere.
(And don't some (old) browsers send */* always?)
So it's will need some sort of configuration mechanism to make it
endpoint specific.
Good news - every UpdateProcessor has a Context object that is
associated with the request. It's currently null for a remote request
but the mechanism is at least there.
Remote query (either QueryExecutionFactory.sparelService or SERVICE in a
query) has a mechanism for setting the request with custom headers.
See ARQ.serviceParams and class Service.
Do you want to raise a JIRA for this? And (ideally) contribute a patch?
Andy
On 05/12/12 21:43, Simon Gábor wrote:
Hi Andy,
I am trying to use Dydra (http://dydra.com/). It requires to send Accept
header, otherwise it returns with a full HTML webpage (with Dydra's online
query tool on it). For update commands it is happy with just an Accept: */*
then returns 200 and a simple boolean SPARQL XML result.
Example:
POST http://dydra.com/orkszoft/test01/sparql HTTP/1.1
Accept: */*
Content-Length: 364
Content-Type: application/sparql-update
Host: dydra.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.2.2 (java 1.5)
Authorization: Basic ***
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
DELETE DATA {
<http://dbpedia.org/resource/San_Francisco> rdfs:label "My San Francisco"
.
}
Response:
HTTP/1.1 200 OK
Content-Type: */*
Connection: keep-alive
Status: 200
X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.9
Cache-Control: no-cache
X-UA-Compatible: IE=Edge,chrome=1
Set-Cookie: _dydra_session=****; path=/; HttpOnly
X-Runtime: 0.849964
Server: nginx/1.0.8 + Phusion Passenger 3.0.9 (mod_rails/mod_rack)
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: *
Content-Length: 123
<?xml version='1.0'?>
<sparql xmlns='http://www.w3.org/2005/sparql-results#'>
<head/>
<boolean>true</boolean>
</sparql>
I'm having trouble to decide whether Dydra has a faulty design (it's not
conform with the protocol recommendation) or Jena has no support for the
optional content negotiation (or both)?
It's for sure that Dydra's method is somewhat weird because for a wrong
SPARQL it returns code 400 - so it seems that the response body holds no
new info.
Gabor Simon
2012/12/5 Andy Seaborne <[email protected]>
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<http://tools.ietf.org/html/draft-nottingham-http-problem-01>
