On 12/6/12 12:31 PM, "Andy Seaborne" <[email protected]> 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 <[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_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" <[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> >>>>>> >>>>> >>>> >>> >
