You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Simon Gábor <sg...@gmail.com> on 2012/12/03 13:44:28 UTC
arq - accept header in remote SPARQL update
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.
Thanks in advance,
Gabor Simon
Re: arq - accept header in remote SPARQL update
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org> 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
>
>
>
Re: arq - accept header in remote SPARQL update
Posted by Claude Warren <cl...@xenei.com>.
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.
On Wed, Dec 5, 2012 at 11:52 AM, Andy Seaborne <an...@apache.org> 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
--
I like: Like Like - The likeliest place on the web
Identity: https://www.identify.nu/user.php?claude@xenei.com
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: arq - accept header in remote SPARQL update
Posted by Simon Gábor <sg...@gmail.com>.
Ok, i will ask Dydra first whether this kind of conneg is a bug or a
feature.
2012/12/6 Rob Vesse <rv...@yarcdata.com>
> My two cents:
>
> In my experience of writing a HTTP connector for Dydra for dotNetRDF it
> proved to be a pretty awful implementation of HTTP conneg and SPARQL
> protocols in general compared to other similar systems like Sesame,
> Stardog, Fuseki etc. and I had to put an awful lot of implementation
> specific hacks in place to get things working.
>
> For example I have a still open bug related to something very similar to
> this
> (
> https://getsatisfaction.com/dydra/topics/basic_digest_http_authentication_
> is_not_supported) which relates to them doing dumb stuff with conneg and
> not just using HTTP authentication nicely. In essence if you are not
> logged in and the Accept header does not ask for machine readable formats
> they automatically redirect to a HTML login form instead of doing HTTP
> auth. This is particularly problematic because their processing of the
> Accept header is poor, if you so much as mention HTML in there it will
> think you are a browser even if machine readable formats are ahead of HTML
> in the Accept header.
>
> I agree with Andy that maybe there is some room for improvement in Jena to
> allow this to be configured in general but I wouldn't want to turn this on
> in general just to work with Dydra which I'm still expecting to die a
> death. I know for a fact that one of their core developers has long since
> parted ways with the company and I haven't seen any activity on any of my
> various open bugs in a long time.
>
> Rob
>
>
> On 12/6/12 3:14 AM, "Andy Seaborne" <an...@apache.org> wrote:
>
> >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 <an...@apache.org>
> >>
> >>> 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://t
> >>>ools.ietf.org/html/draft-nottingham-http-problem-01>
> >>>
> >>
> >
>
>
Re: arq - accept header in remote SPARQL update
Posted by Andy Seaborne <an...@apache.org>.
On 06/12/12 20:49, Stephen Allen wrote:
>> However perhaps we should be ensuring that everywhere that does anything
>> HTTP uses the Apache HttpClient as a point of standardization and provide
>> ways to better expose that up to users to add custom configuration?
On the way to that : the idea of HttpOp is to abstract away from the
choice of HTTP library for many common uses of HTTP in Jena/ARQ.
. Without writing yet another HTTP library or getting into JAR bloat.
HttpOp2 =>
TypedInputStreamHttp execHttpGet(String url, String acceptHeader)
HttpQuery could do with an update to use Apache HttpClient.
((
Fuseki has a simple abstraction of an operation request.
It has it's conneg (one class) which has existed for years.
Must of the real work is not in the general HTTP handling anyway but in
the specifics of writing ResultSets and Model and the protocol extensions.
))
>>
>> As Andy says patches are welcome in this area. I know I've done some work
>> in the past to improve configurability on the remote query side but it
>> still uses the java.net APIs rather than HttpClient as the remote update
>> stuff does.
>
> HttpClient is nice for what it does, but unfortunately it hides some
> of the capabilities of the java.net APIs. In particular for
> jena-client, I could not use it because I needed direct access to the
> OutputStream for streaming capabilities [1]. The closest you can get
> in HttpClient is InputStreamEntity, which would require an inversion
> of control and thus a separate thread in some situations
Yes, I found that a nuisance as well - the receive side can be streamed
but the sending side can't. The pain hidden in HTTP is the need to have
retryable operations for authentication or due to temporary failure.
To some extend HTTP, as deployed, is not a streaming protocol. e.g. The
status code of a response has to be first which is a nuisance if
generating the response body might cause an error of some kind. Teh
lack of stream out
I find this permeates the design space - assemble all the content, then
do the operation.
So lucky you can use one API in one place and another API in another.
Andy
>
> -Stephen
>
> [1] http://svn.apache.org/repos/asf/jena/Experimental/jena-client/src/main/java/org/apache/jena/client/http/HttpUpdater.java
>
Re: arq - accept header in remote SPARQL update
Posted by Stephen Allen <sa...@apache.org>.
On Thu, Dec 6, 2012 at 3:36 PM, Rob Vesse <rv...@yarcdata.com> wrote:
> On 12/6/12 12:31 PM, "Andy Seaborne" <an...@apache.org> wrote:
>
>
>>On 06/12/12 20:03, Martynas Jusevičius wrote:
>>> If Jena would be consistent in its HTTP handling and use an
>>> established API such as JAX-RS, things could be much easier.
>>
>>Could you explain that a bit more so we can see what can be improved (or
>>submit a patch)? Do you have specific suggestions?
>>
>>JAX-RS is an API for mapping Java with annotations to web resources.
>>
>>HTTP is a protocol.
>
> I agree, I don't see how JAX-RS is relevant here.
>
> However perhaps we should be ensuring that everywhere that does anything
> HTTP uses the Apache HttpClient as a point of standardization and provide
> ways to better expose that up to users to add custom configuration?
>
> As Andy says patches are welcome in this area. I know I've done some work
> in the past to improve configurability on the remote query side but it
> still uses the java.net APIs rather than HttpClient as the remote update
> stuff does.
HttpClient is nice for what it does, but unfortunately it hides some
of the capabilities of the java.net APIs. In particular for
jena-client, I could not use it because I needed direct access to the
OutputStream for streaming capabilities [1]. The closest you can get
in HttpClient is InputStreamEntity, which would require an inversion
of control and thus a separate thread in some situations
-Stephen
[1] http://svn.apache.org/repos/asf/jena/Experimental/jena-client/src/main/java/org/apache/jena/client/http/HttpUpdater.java
Re: arq - accept header in remote SPARQL update
Posted by Andy Seaborne <an...@apache.org>.
On 06/12/12 20:48, Martynas Jusevičius wrote:
> Andy, we've been through this already:
> http://mail-archives.eu.apache.org/mod_mbox/jena-users/201202.mbox/%3CCAE35VmzPcczXsWt37ETsB_5BzW6qGV-UUFPhy8BX6SSH4U9nFA@mail.gmail.com%3E
Have you looked at Stephen's work on jena-client?
> OK, maybe I should say JAX-RS and Jersey as its implementation, which
> also includes the client.
The question is about what's on the wire.
Dydra returns HTML when no content was asked for. It was a POST with
the request content type as application/sparql-update. And no "Accept"
because there is no wanted reply.
Why not 204?
And why is a SPARQL query result set returned for */*?
> JAX-RS allows not only high-level annotations, but also low-level
> conneg if there is a need for it, both on server and client sides.
>
> Here's an example of actual code I have at hand:
>
> ResultSet resultSet = getResultSet();
> EntityTag entityTag = new
> EntityTag(Long.toHexString(ResultSetUtils.hashResultSet(resultSet)));
> Response.ResponseBuilder rb =
> getRequest().evaluatePreconditions(entityTag);
>
> if (rb != null)
> {
> if (log.isTraceEnabled()) log.trace("Resource not modified, skipping
> Response generation");
> return rb.build();
> }
> else
> {
> Variant variant = getRequest().selectVariant(RESULT_SET_VARIANTS);
> if (variant == null)
> {
> if (log.isTraceEnabled()) log.trace("Requested Variant {} is not
> on the list of acceptable Response Variants: {}", variant,
> getVariants());
> return Response.notAcceptable(RESULT_SET_VARIANTS).build();
> }
> else
> {
> if (log.isTraceEnabled()) log.trace("Generating SPARQL results
> Response with Variant: {} and EntityTag: {}", variant, entityTag);
> return Response.ok(resultSet, variant).tag(entityTag).build();
> // uses ResultSetWriter
> }
> }
That is the server side of a query operation.
The question is about the client side of an update operation.
The point about using a standard (SPARQL Protocol) is that the client
library (ARQ) can provide one single call operation to send a SPARQL
Update to the server. It's higher level than exposing HTTP details.
> Jena has different HTTP code scattered all over the place,
Really?
HttpQuery is the only mention of HttpURLConnection in ARQ I can find.
All use in jena-core is to be replace by the new RIOT reader (and is
already if you have ARQ initialized).
For SPARQL Update and model reading, ARQ uses Apache Common HttpClient.
This is in 2 files and soon to be 1 -- HttpOp and the new material to
be merged from HttpOp2.
> while
> JAX-RS/Jersey covers all HTTP use cases (that I came across) within
> Linked Data -- what else do we need?
Encapsulation of low level details.
Andy
>
> Martynas
>
> On Thu, Dec 6, 2012 at 10:36 PM, Rob Vesse <rv...@yarcdata.com> wrote:
>> On 12/6/12 12:31 PM, "Andy Seaborne" <an...@apache.org> wrote:
>>
>>
>>> On 06/12/12 20:03, Martynas Jusevičius wrote:
>>>> If Jena would be consistent in its HTTP handling and use an
>>>> established API such as JAX-RS, things could be much easier.
>>>
>>> Could you explain that a bit more so we can see what can be improved (or
>>> submit a patch)? Do you have specific suggestions?
>>>
>>> JAX-RS is an API for mapping Java with annotations to web resources.
>>>
>>> HTTP is a protocol.
>>
>> I agree, I don't see how JAX-RS is relevant here.
>>
>> However perhaps we should be ensuring that everywhere that does anything
>> HTTP uses the Apache HttpClient as a point of standardization and provide
>> ways to better expose that up to users to add custom configuration?
>>
>> As Andy says patches are welcome in this area. I know I've done some work
>> in the past to improve configurability on the remote query side but it
>> still uses the java.net APIs rather than HttpClient as the remote update
>> stuff does.
>>
>>>
>>> The question is about the use of content negotiation on SPARQL update
>>> requests i.e. the bits on the wire. Surely the client API or server
>>> implementation should work with any legal bits on the wire (and be
>>> defensive about illegal bits?)
>>
>> +Many
>>
>> Though we should consider Postel's law here - "Be liberal in what you
>> accept and conservative in what you send"
>>
>> In this particular case we are complying with this and Dydra is not as I
>> see it.
>>
>> Rob
>>
>>>
>>> Andy
>>>
>>>
>>>
>>>>
>>>> Martynas
>>>> graphity.org
>>>>
>>>> On Thu, Dec 6, 2012 at 6:04 PM, Rob Vesse <rv...@yarcdata.com> wrote:
>>>>> My two cents:
>>>>>
>>>>> In my experience of writing a HTTP connector for Dydra for dotNetRDF it
>>>>> proved to be a pretty awful implementation of HTTP conneg and SPARQL
>>>>> protocols in general compared to other similar systems like Sesame,
>>>>> Stardog, Fuseki etc. and I had to put an awful lot of implementation
>>>>> specific hacks in place to get things working.
>>>>>
>>>>> For example I have a still open bug related to something very similar
>>>>> to
>>>>> this
>>>>>
>>>>> (https://getsatisfaction.com/dydra/topics/basic_digest_http_authenticati
>>>>> on_
>>>>> is_not_supported) which relates to them doing dumb stuff with conneg
>>>>> and
>>>>> not just using HTTP authentication nicely. In essence if you are not
>>>>> logged in and the Accept header does not ask for machine readable
>>>>> formats
>>>>> they automatically redirect to a HTML login form instead of doing HTTP
>>>>> auth. This is particularly problematic because their processing of the
>>>>> Accept header is poor, if you so much as mention HTML in there it will
>>>>> think you are a browser even if machine readable formats are ahead of
>>>>> HTML
>>>>> in the Accept header.
>>>>>
>>>>> I agree with Andy that maybe there is some room for improvement in
>>>>> Jena to
>>>>> allow this to be configured in general but I wouldn't want to turn
>>>>> this on
>>>>> in general just to work with Dydra which I'm still expecting to die a
>>>>> death. I know for a fact that one of their core developers has long
>>>>> since
>>>>> parted ways with the company and I haven't seen any activity on any of
>>>>> my
>>>>> various open bugs in a long time.
>>>>>
>>>>> Rob
>>>>>
>>>>>
>>>>> On 12/6/12 3:14 AM, "Andy Seaborne" <an...@apache.org> wrote:
>>>>>
>>>>>> 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 <an...@apache.org>
>>>>>>>
>>>>>>>> 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:
>>>>>>>> //t
>>>>>>>> ools.ietf.org/html/draft-nottingham-http-problem-01>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
Re: arq - accept header in remote SPARQL update
Posted by Martynas Jusevičius <ma...@graphity.org>.
Andy, we've been through this already:
http://mail-archives.eu.apache.org/mod_mbox/jena-users/201202.mbox/%3CCAE35VmzPcczXsWt37ETsB_5BzW6qGV-UUFPhy8BX6SSH4U9nFA@mail.gmail.com%3E
OK, maybe I should say JAX-RS and Jersey as its implementation, which
also includes the client.
JAX-RS allows not only high-level annotations, but also low-level
conneg if there is a need for it, both on server and client sides.
Here's an example of actual code I have at hand:
ResultSet resultSet = getResultSet();
EntityTag entityTag = new
EntityTag(Long.toHexString(ResultSetUtils.hashResultSet(resultSet)));
Response.ResponseBuilder rb =
getRequest().evaluatePreconditions(entityTag);
if (rb != null)
{
if (log.isTraceEnabled()) log.trace("Resource not modified, skipping
Response generation");
return rb.build();
}
else
{
Variant variant = getRequest().selectVariant(RESULT_SET_VARIANTS);
if (variant == null)
{
if (log.isTraceEnabled()) log.trace("Requested Variant {} is not
on the list of acceptable Response Variants: {}", variant,
getVariants());
return Response.notAcceptable(RESULT_SET_VARIANTS).build();
}
else
{
if (log.isTraceEnabled()) log.trace("Generating SPARQL results
Response with Variant: {} and EntityTag: {}", variant, entityTag);
return Response.ok(resultSet, variant).tag(entityTag).build();
// uses ResultSetWriter
}
}
Jena has different HTTP code scattered all over the place, while
JAX-RS/Jersey covers all HTTP use cases (that I came across) within
Linked Data -- what else do we need?
Martynas
On Thu, Dec 6, 2012 at 10:36 PM, Rob Vesse <rv...@yarcdata.com> wrote:
> On 12/6/12 12:31 PM, "Andy Seaborne" <an...@apache.org> wrote:
>
>
>>On 06/12/12 20:03, Martynas Jusevičius wrote:
>>> If Jena would be consistent in its HTTP handling and use an
>>> established API such as JAX-RS, things could be much easier.
>>
>>Could you explain that a bit more so we can see what can be improved (or
>>submit a patch)? Do you have specific suggestions?
>>
>>JAX-RS is an API for mapping Java with annotations to web resources.
>>
>>HTTP is a protocol.
>
> I agree, I don't see how JAX-RS is relevant here.
>
> However perhaps we should be ensuring that everywhere that does anything
> HTTP uses the Apache HttpClient as a point of standardization and provide
> ways to better expose that up to users to add custom configuration?
>
> As Andy says patches are welcome in this area. I know I've done some work
> in the past to improve configurability on the remote query side but it
> still uses the java.net APIs rather than HttpClient as the remote update
> stuff does.
>
>>
>>The question is about the use of content negotiation on SPARQL update
>>requests i.e. the bits on the wire. Surely the client API or server
>>implementation should work with any legal bits on the wire (and be
>>defensive about illegal bits?)
>
> +Many
>
> Though we should consider Postel's law here - "Be liberal in what you
> accept and conservative in what you send"
>
> In this particular case we are complying with this and Dydra is not as I
> see it.
>
> Rob
>
>>
>> Andy
>>
>>
>>
>>>
>>> Martynas
>>> graphity.org
>>>
>>> On Thu, Dec 6, 2012 at 6:04 PM, Rob Vesse <rv...@yarcdata.com> wrote:
>>>> My two cents:
>>>>
>>>> In my experience of writing a HTTP connector for Dydra for dotNetRDF it
>>>> proved to be a pretty awful implementation of HTTP conneg and SPARQL
>>>> protocols in general compared to other similar systems like Sesame,
>>>> Stardog, Fuseki etc. and I had to put an awful lot of implementation
>>>> specific hacks in place to get things working.
>>>>
>>>> For example I have a still open bug related to something very similar
>>>>to
>>>> this
>>>>
>>>>(https://getsatisfaction.com/dydra/topics/basic_digest_http_authenticati
>>>>on_
>>>> is_not_supported) which relates to them doing dumb stuff with conneg
>>>>and
>>>> not just using HTTP authentication nicely. In essence if you are not
>>>> logged in and the Accept header does not ask for machine readable
>>>>formats
>>>> they automatically redirect to a HTML login form instead of doing HTTP
>>>> auth. This is particularly problematic because their processing of the
>>>> Accept header is poor, if you so much as mention HTML in there it will
>>>> think you are a browser even if machine readable formats are ahead of
>>>>HTML
>>>> in the Accept header.
>>>>
>>>> I agree with Andy that maybe there is some room for improvement in
>>>>Jena to
>>>> allow this to be configured in general but I wouldn't want to turn
>>>>this on
>>>> in general just to work with Dydra which I'm still expecting to die a
>>>> death. I know for a fact that one of their core developers has long
>>>>since
>>>> parted ways with the company and I haven't seen any activity on any of
>>>>my
>>>> various open bugs in a long time.
>>>>
>>>> Rob
>>>>
>>>>
>>>> On 12/6/12 3:14 AM, "Andy Seaborne" <an...@apache.org> wrote:
>>>>
>>>>> 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 <an...@apache.org>
>>>>>>
>>>>>>> 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:
>>>>>>>//t
>>>>>>> ools.ietf.org/html/draft-nottingham-http-problem-01>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
Re: arq - accept header in remote SPARQL update
Posted by Rob Vesse <rv...@yarcdata.com>.
On 12/6/12 12:31 PM, "Andy Seaborne" <an...@apache.org> wrote:
>On 06/12/12 20:03, Martynas Jusevičius wrote:
>> If Jena would be consistent in its HTTP handling and use an
>> established API such as JAX-RS, things could be much easier.
>
>Could you explain that a bit more so we can see what can be improved (or
>submit a patch)? Do you have specific suggestions?
>
>JAX-RS is an API for mapping Java with annotations to web resources.
>
>HTTP is a protocol.
I agree, I don't see how JAX-RS is relevant here.
However perhaps we should be ensuring that everywhere that does anything
HTTP uses the Apache HttpClient as a point of standardization and provide
ways to better expose that up to users to add custom configuration?
As Andy says patches are welcome in this area. I know I've done some work
in the past to improve configurability on the remote query side but it
still uses the java.net APIs rather than HttpClient as the remote update
stuff does.
>
>The question is about the use of content negotiation on SPARQL update
>requests i.e. the bits on the wire. Surely the client API or server
>implementation should work with any legal bits on the wire (and be
>defensive about illegal bits?)
+Many
Though we should consider Postel's law here - "Be liberal in what you
accept and conservative in what you send"
In this particular case we are complying with this and Dydra is not as I
see it.
Rob
>
> Andy
>
>
>
>>
>> Martynas
>> graphity.org
>>
>> On Thu, Dec 6, 2012 at 6:04 PM, Rob Vesse <rv...@yarcdata.com> wrote:
>>> My two cents:
>>>
>>> In my experience of writing a HTTP connector for Dydra for dotNetRDF it
>>> proved to be a pretty awful implementation of HTTP conneg and SPARQL
>>> protocols in general compared to other similar systems like Sesame,
>>> Stardog, Fuseki etc. and I had to put an awful lot of implementation
>>> specific hacks in place to get things working.
>>>
>>> For example I have a still open bug related to something very similar
>>>to
>>> this
>>>
>>>(https://getsatisfaction.com/dydra/topics/basic_digest_http_authenticati
>>>on_
>>> is_not_supported) which relates to them doing dumb stuff with conneg
>>>and
>>> not just using HTTP authentication nicely. In essence if you are not
>>> logged in and the Accept header does not ask for machine readable
>>>formats
>>> they automatically redirect to a HTML login form instead of doing HTTP
>>> auth. This is particularly problematic because their processing of the
>>> Accept header is poor, if you so much as mention HTML in there it will
>>> think you are a browser even if machine readable formats are ahead of
>>>HTML
>>> in the Accept header.
>>>
>>> I agree with Andy that maybe there is some room for improvement in
>>>Jena to
>>> allow this to be configured in general but I wouldn't want to turn
>>>this on
>>> in general just to work with Dydra which I'm still expecting to die a
>>> death. I know for a fact that one of their core developers has long
>>>since
>>> parted ways with the company and I haven't seen any activity on any of
>>>my
>>> various open bugs in a long time.
>>>
>>> Rob
>>>
>>>
>>> On 12/6/12 3:14 AM, "Andy Seaborne" <an...@apache.org> wrote:
>>>
>>>> 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 <an...@apache.org>
>>>>>
>>>>>> 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:
>>>>>>//t
>>>>>> ools.ietf.org/html/draft-nottingham-http-problem-01>
>>>>>>
>>>>>
>>>>
>>>
>
Re: arq - accept header in remote SPARQL update
Posted by Andy Seaborne <an...@apache.org>.
On 06/12/12 20:03, Martynas Jusevičius wrote:
> If Jena would be consistent in its HTTP handling and use an
> established API such as JAX-RS, things could be much easier.
Could you explain that a bit more so we can see what can be improved (or
submit a patch)? Do you have specific suggestions?
JAX-RS is an API for mapping Java with annotations to web resources.
HTTP is a protocol.
The question is about the use of content negotiation on SPARQL update
requests i.e. the bits on the wire. Surely the client API or server
implementation should work with any legal bits on the wire (and be
defensive about illegal bits?)
Andy
>
> Martynas
> graphity.org
>
> On Thu, Dec 6, 2012 at 6:04 PM, Rob Vesse <rv...@yarcdata.com> wrote:
>> My two cents:
>>
>> In my experience of writing a HTTP connector for Dydra for dotNetRDF it
>> proved to be a pretty awful implementation of HTTP conneg and SPARQL
>> protocols in general compared to other similar systems like Sesame,
>> Stardog, Fuseki etc. and I had to put an awful lot of implementation
>> specific hacks in place to get things working.
>>
>> For example I have a still open bug related to something very similar to
>> this
>> (https://getsatisfaction.com/dydra/topics/basic_digest_http_authentication_
>> is_not_supported) which relates to them doing dumb stuff with conneg and
>> not just using HTTP authentication nicely. In essence if you are not
>> logged in and the Accept header does not ask for machine readable formats
>> they automatically redirect to a HTML login form instead of doing HTTP
>> auth. This is particularly problematic because their processing of the
>> Accept header is poor, if you so much as mention HTML in there it will
>> think you are a browser even if machine readable formats are ahead of HTML
>> in the Accept header.
>>
>> I agree with Andy that maybe there is some room for improvement in Jena to
>> allow this to be configured in general but I wouldn't want to turn this on
>> in general just to work with Dydra which I'm still expecting to die a
>> death. I know for a fact that one of their core developers has long since
>> parted ways with the company and I haven't seen any activity on any of my
>> various open bugs in a long time.
>>
>> Rob
>>
>>
>> On 12/6/12 3:14 AM, "Andy Seaborne" <an...@apache.org> wrote:
>>
>>> 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 <an...@apache.org>
>>>>
>>>>> 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://t
>>>>> ools.ietf.org/html/draft-nottingham-http-problem-01>
>>>>>
>>>>
>>>
>>
Re: arq - accept header in remote SPARQL update
Posted by Martynas Jusevičius <ma...@graphity.org>.
If Jena would be consistent in its HTTP handling and use an
established API such as JAX-RS, things could be much easier.
Martynas
graphity.org
On Thu, Dec 6, 2012 at 6:04 PM, Rob Vesse <rv...@yarcdata.com> wrote:
> My two cents:
>
> In my experience of writing a HTTP connector for Dydra for dotNetRDF it
> proved to be a pretty awful implementation of HTTP conneg and SPARQL
> protocols in general compared to other similar systems like Sesame,
> Stardog, Fuseki etc. and I had to put an awful lot of implementation
> specific hacks in place to get things working.
>
> For example I have a still open bug related to something very similar to
> this
> (https://getsatisfaction.com/dydra/topics/basic_digest_http_authentication_
> is_not_supported) which relates to them doing dumb stuff with conneg and
> not just using HTTP authentication nicely. In essence if you are not
> logged in and the Accept header does not ask for machine readable formats
> they automatically redirect to a HTML login form instead of doing HTTP
> auth. This is particularly problematic because their processing of the
> Accept header is poor, if you so much as mention HTML in there it will
> think you are a browser even if machine readable formats are ahead of HTML
> in the Accept header.
>
> I agree with Andy that maybe there is some room for improvement in Jena to
> allow this to be configured in general but I wouldn't want to turn this on
> in general just to work with Dydra which I'm still expecting to die a
> death. I know for a fact that one of their core developers has long since
> parted ways with the company and I haven't seen any activity on any of my
> various open bugs in a long time.
>
> Rob
>
>
> On 12/6/12 3:14 AM, "Andy Seaborne" <an...@apache.org> wrote:
>
>>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 <an...@apache.org>
>>>
>>>> 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://t
>>>>ools.ietf.org/html/draft-nottingham-http-problem-01>
>>>>
>>>
>>
>
Re: arq - accept header in remote SPARQL update
Posted by Rob Vesse <rv...@yarcdata.com>.
My two cents:
In my experience of writing a HTTP connector for Dydra for dotNetRDF it
proved to be a pretty awful implementation of HTTP conneg and SPARQL
protocols in general compared to other similar systems like Sesame,
Stardog, Fuseki etc. and I had to put an awful lot of implementation
specific hacks in place to get things working.
For example I have a still open bug related to something very similar to
this
(https://getsatisfaction.com/dydra/topics/basic_digest_http_authentication_
is_not_supported) which relates to them doing dumb stuff with conneg and
not just using HTTP authentication nicely. In essence if you are not
logged in and the Accept header does not ask for machine readable formats
they automatically redirect to a HTML login form instead of doing HTTP
auth. This is particularly problematic because their processing of the
Accept header is poor, if you so much as mention HTML in there it will
think you are a browser even if machine readable formats are ahead of HTML
in the Accept header.
I agree with Andy that maybe there is some room for improvement in Jena to
allow this to be configured in general but I wouldn't want to turn this on
in general just to work with Dydra which I'm still expecting to die a
death. I know for a fact that one of their core developers has long since
parted ways with the company and I haven't seen any activity on any of my
various open bugs in a long time.
Rob
On 12/6/12 3:14 AM, "Andy Seaborne" <an...@apache.org> wrote:
>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 <an...@apache.org>
>>
>>> 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://t
>>>ools.ietf.org/html/draft-nottingham-http-problem-01>
>>>
>>
>
Re: arq - accept header in remote SPARQL update
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org>
>
>> 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>
>>
>
Re: arq - accept header in remote SPARQL update
Posted by Simon Gábor <sg...@gmail.com>.
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 <an...@apache.org>
> 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>
>
Re: arq - accept header in remote SPARQL update
Posted by Andy Seaborne <an...@apache.org>.
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