00:47:40 <LeeF> LeeF has joined #sparql
02:41:18 <AlexPassant> AlexPassant has joined #sparql
03:31:41 <iv_an_ru> iv_an_ru has joined #sparql
07:38:50 <AndyS> AndyS has joined #sparql
08:44:43 <AndyS> AndyS has joined #sparql
08:45:54 <SteveH_> SteveH_ has joined #sparql
09:15:58 <AndyS> AndyS has joined #sparql
10:20:03 <AndyS> SteveH_, good catch on xml:base.
10:20:15 <SteveH_> AndyS, that bit is kinda nuts
10:20:34 <AndyS> Don't panic ! :-) the doc is wrong.
10:21:12 <AndyS> There can be many xml:base in a doc, it only applied to the XML element it is an attribute of.
10:21:34 <SteveH_> that's what I thought, but wasn't 100% sure
10:29:32 <SteveH_> the requirement for handling local URIs is a bit optimisitic as well, I bet not many systems can get that right relaibly
10:30:25 <AndyS> What is the requirement?
10:30:48 <SteveH_> it would be impossible in 4store, and we built our own HTTP server
10:31:07 <SteveH_> ...?graph=foo should reconstruct the correct URI based on the client's request URI
10:31:44 <SteveH_> e.g. if the request was https://server1:8888/data/?graph=foo the graph URI will be https://server1:8888/data/foo
10:31:59 <SteveH_> but in many cases the server has no way to correctly reconstruct that URI
10:32:19 <AndyS> The resolve "foo" against http://example/rdf-graphs/service/?graph=foo  ? 
10:32:52 <SteveH_> let me look what the example was
10:33:06 <SteveH_> the example in the doc was a simple one, which doesn't exhibit the problem
10:33:07 <AndyS> I think that proxies rely sufficient info to reconstruct the original URL but I'm just checking this.
10:33:16 <AndyS> s/rely/relay/
10:33:21 <SteveH_> they don't relay http v's https
10:33:23 <SteveH_> I checked
10:33:34 <AndyS> Ah.  Bother.  Tricky.  
10:33:55 <SteveH_> I'm not convinced they relay the clients requester domain name either, but not sure about that
10:34:02 <AndyS> I'm checking what relayed servlets get to see.
10:34:23 <SteveH_> s/requester/requested/
10:34:25 <AndyS> I have no idea what is real-world behaviour.
10:34:52 <SteveH_> we tend to use apache reverse proxies, not sure how much of their behaviour is req'd or conventional
10:35:14 <SteveH_> I don't think relays/reverse proxies are goverened by any particular standard, but not sure about that
10:44:19 <AndyS> Servlet getRequestURL rebuilds the original URL.  I use apache to gateway "sparql.org" (httpd) to a more protected Jetty instance.
10:47:48 <AndyS> I don't use any clever connector from Apache - it proxies:
10:48:36 <AndyS>   ServerName www.sparql.org
10:48:37 <AndyS>   ProxyRequests off
10:48:37 <AndyS>   ProxyPass / http://127.0.0.1:2020/
10:48:37 <AndyS>   ProxyPassReverse / http://127.0.0.1:2020/
10:48:37 <AndyS>   ProxyPreserveHost On
10:49:44 <AndyS> Hmm - just had to restart httpd - think someone/thing is attacking (maybe by accidient) sparql.org exploiting a Jetty bug.  Have now upgraded and hope it goes away.
10:51:41 <SteveH_> ah, so Apache ProxyPass passes on the requested domain, so that's covered in that case, but not everything has the same featureset as apache, and it still doesn't pass http / https
10:52:07 <SteveH_> wait, no, that's your config
10:52:45 <SteveH_> but if getRequestURL rebuilds it, the data must be there somewhere
11:01:54 <AndyS> time to get out wireshark
11:02:48 <SteveH_> or nc :)
11:06:47 <AndyS> (that's a cut down config extract)
11:07:24 <SteveH_> right
11:08:00 <AndyS> Not sure it passes http/https but if https -> https and http->http then OK and works as backend does the https (e.g. cert) not front public facing.
11:15:43 <SteveH_> we do https -> http for 4/5store because our server doesn't speak https
11:16:08 <SteveH_> we also do it for jetty in datapatrol because there's something wrong with jetty's https support (apparently)
11:16:24 <SteveH_> I know nothing about jetty