Relative URIs are resolved incorrectly after redirects

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Prepare a resource <http://example.org/foo> serving up an RDF description 
that contains relative URIs, for example <#frag1>.
2. Prepare a resource <http://example.org/bar> that redirects (for example, 
HTTP 301) to <http://example.org/foo>.
3. Use RDFLib's Graph.parse() to parse <http://example.org/bar>.

What is the expected output? What do you see instead?
I expect the "real" URI <http://example.org/foo> to be used as the base URI, 
giving absolute URIs of the form <http://example.org/foo#frag1>. Instead, 
RDFLib uses the original requested URI <http://example.org/bar> as the base, 
giving <http://example.org/bar#frag1>.

What version of the product are you using? On what operating system?
RDFLib trunk (r1895) on GNU/Linux.

Please provide any additional information below.
RFC 3986 Uniform Resource Identifier (URI): Generic Syntax
http://tools.ietf.org/html/rfc3986#section-5.1.3
"Note that if the retrieval was the result of a redirected request, the last 
URI used (i.e., the URI that resulted in the actual retrieval of the 
representation) is the base URI."

Original issue reported on code.google.com by vfaronov on 10 Sep 2010 at 11:23

[GoogleCodeExporter]

For a working example, see <http://linked-data.ru/example> which 301s to 
<http://linked-data.ru/example/> (RDFa).

Original comment by vfaronov on 10 Sep 2010 at 11:30

[GoogleCodeExporter]

First attempt at a patch.
This changes the base URI resolution logic a bit, and I'm not 100% sure it 
doesn't break anything.

Original comment by vfaronov on 11 Sep 2010 at 11:37

Attachments:

• issue140-relative.patch