W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > December 2012

Re: Possible Bug in SPARQL 1.1 Protocol Validator

From: Gregory Williams <greg@evilfunhouse.com>
Date: Tue, 18 Dec 2012 16:56:50 -0500
Cc: <public-rdf-dawg-comments@w3.org>
Message-Id: <C350A13E-A4F6-45F4-9257-F8FFB1B637AD@evilfunhouse.com>
To: Rob Vesse <rvesse@dotnetrdf.org>
On Dec 17, 2012, at 6:03 PM, Rob Vesse wrote:

> After some digging in the Perl code I have identified what might be the
> root cause of the problem, in the relevant tests the URIs are created like
> so:
> 
> POST("${uurl}?using-graph-uri=http%3A%2F%2Fkasei.us%2F2009%2F09%2Fsparql%2F
> data%2Fdata1.rdf&using-named-graph-uri=http%3A%2F%2Fkasei.us%2F2009%2F09%2F
> sparql%2Fdata%2Fdata2.rdf", [
> 						'update' => $sparql,
> 					]);
> 
> This appears to result in double encoding of the using-graph-uri and
> using-named-graph parameters and since .Net only decodes the parameters
> once for me (and I am clearly not going to decode them multiple times) the
> SPARQL Updates end up not creating the expected data because the graph
> URIs are incorrect.


Hi Rob,

Where are you seeing the double encoding? I'm able to take that POST line, run it, and see this on the server side:

------------
POST /?using-graph-uri=http%3A%2F%2Fkasei.us%2F2009%2F09%2Fsparql%2F%20data%2Fdata1.rdf&using-named-graph-uri=http%3A%2F%2Fkasei.us%2F2009%2F09%2F%20sparql%2Fdata%2Fdata2.rdf HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: localhost:8881
User-Agent: libwww-perl/5.834
Content-Length: 27
Content-Type: application/x-www-form-urlencoded

update=sparql+update+string
------------

Do you believe this is wrongly encoded? Given that there are several implementations passing the protocol tests using this validator (I know of ones in perl, java, and c++), I believe the problem may lie elsewhere.

> In my Java harness it is passing the unencoded form through Apache HTTP
> Client and this encodes the URI only once so I get the
> correct URI on the server side and the tests pass.
> 
> I verified that double encoding does indeed appear to be the root cause of
> the problem by replacing the unencoded form with the encoded form in my
> Java test harness and then the tests start failing.

This sounds like it might be a difference between the perl and java http library APIs...?

> So it looks like the Perl code should be as follows:
> 
> POST("${uurl}?using-graph-uri=http://kasei.us/2009/09/sparql/
> data/data1.rdf&using-named-graph-uri=http://kasei.us/2009/09/sparql/data/da
> ta2.rdf", [
> 						'update' => $sparql,
> 					]);
> 
> I.e. the URLs should not be encoded as LWP should take care of this
> automatically AFAICT

That does not seem to be the case with the version of LWP I am using.


> However I am not 100% certain that double encoding is the issue because
> other implementations like Fuseki seem to be totally fine.
> 
> I have spent some time trying to get the protocol validator running in an
> Apache instance on my OS X laptop but have had little luck.  There is an
> apparent undeclared dependency on TryCatch which won't install properly
> under OS X for reasons unbeknownst to me and after forcing install the
> script just fails to run with a vague and unhelpful compilation error in
> the Apache logs.

Yes, TryCatch is required, as is Plack. I can update the documentation, but not sure how else to debug the problem as it works locally for me, and is working on my server where the validator is being hosted.

.greg
Received on Tuesday, 18 December 2012 21:57:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 18 December 2012 21:57:13 GMT