Ok, i will ask Dydra first whether this kind of conneg is a bug or a feature.
2012/12/6 Rob Vesse <[email protected]> > 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> > >>> > >> > > > >
