IRC log of sparql on 2010-10-06
Timestamps are in UTC.
- 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