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!
