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 <[email protected]> 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" <[email protected]> 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 <[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://t >>>>ools.ietf.org/html/draft-nottingham-http-problem-01> >>>> >>> >> >
