Hi Ivan,
Thanks I'll check this workaround.
BTW - These are the headers generated internally by the Sesame
HTTPRepository client.
Regards,
A
Sent from my iPhone
On May 22, 2009, at 11:18 AM, Ivan Mikhailov
<imikhai...@openlinksw.com> wrote:
Hello Aldo,
It seems to me that we have problem with multiple Accept: lines in the
HTTP header. If I swap two lines and send
Accept: application/sparql-results+xml;q=0.8
Accept: application/x-binary-rdf-results-table
Accept: application/xml;q=0.8
then it works. (I don't know whether it should return an empty
result-set but it does not produce an error.)
I hope that the fix will come quickly.
Best Regards,
Ivan Mikhailov
OpenLink Software
http://virtuoso.openlinksw.com
On Thu, 2009-05-21 at 22:33 -0400, Aldo Bucchi wrote:
Hi,
On Tue, May 19, 2009 at 6:25 PM, Kingsley Idehen <kide...@openlinksw.com
> wrote:
Aldo Bucchi wrote:
Hi,
I am receiving an HTTP error when querying lod.openlinksw.com/
sparql
The query is valid SPARQL, trust me. This appears to be a CN
error of some
kind.
POST /sparql HTTP/1.1
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Accept: application/x-binary-rdf-results-table
Accept: application/sparql-results+xml;q=0.8
Accept: application/xml;q=0.8
User-Agent: Jakarta Commons-HttpClient/3.1
Host: lod.openlinksw.com
Content-Length: 662
queryLn=SPARQL&query=SELECT+%3Fvalue+WHERE+%7B+%3Chttp%3A%2F%2Fwww.univrz.com
%2Fdataspace%2Fperson%2Faldo.bucchi%23this%3E+%3Fp+%3Fvalue+.
+FILTER%28+%3Fp+%3D+%3Chttp%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-
schema%23label%3E+%7C%7C+%3Fp+%3D+%3Chttp%3A%2F%2Fdbpedia.org
%2Fproperty%2Fname%3E+%7C%7C+%3Fp+%3D+%3Chttp%3A%2F%2Fxmlns.com
%2Ffoaf%2F0.1%2Fname%3E+%7C%7C+%3Fp+%3D+%3Chttp%3A%2F%2Fpurl.org
%2Fdc%2Felements%2F1.1%2Ftitle%3E+%7C%7C+%3Fp+%3D+%3Chttp%3A%2F
%2Frdfs.org%2Fsioc%2Fns%23name%3E+%7C%7C+%3Fp+%3D+%3Chttp%3A%2F%2Fwww.w3.org
%2F2005%2FAtom%23title%3E+%7C%7C+%3Fp+%3D+%3Chttp%3A%2F%2Fwww.w3.org
%2F2004%2F02%2Fskos%2Fcore%23label%3E+%29+%7D+LIMIT+1&infer=true
HTTP/1.1 406 Unacceptable
Server: Virtuoso/06.00.3119 (Linux) x86_64-unknown-linux-gnu VDB
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
Date: Tue, 19 May 2009 21:43:24 GMT
Accept-Ranges: bytes
Alternates: {"sparql" 1 {type application/sparql-results+xml}
{charset
UTF-8} {length 292}}
Content-Length: 383
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>406 Not Acceptable</title>
</head><body>
<h1>406 Not Acceptable</h1>
<p>An appropriate representation of the requested resource sparql
could not be found on this server.</p>
Available variant(s):
<ul>
<li><a href="sparql">sparql</a> , type application/sparql-results
+xml,
charset UTF-8</li>
</ul>
</body></html>
Yes, it looks like a transparent content negotiation glitch
introduced by
the latest binary behind that instance :-(
Anyway, we'll double check.
I can confirm we now introduced this bug to a V5 instance when
upgrading, so it is most probably something recent.
This kills our SPARQLing clients, thus rendering our apps unusable.
Yikes!
