W3C home > Mailing lists > Public > www-tag@w3.org > October 2010

Re: XML base after redirection

From: Graham Klyne <GK-lists@ninebynine.org>
Date: Tue, 26 Oct 2010 17:06:59 +0100
Message-ID: <4CC6FCA3.10809@ninebynine.org>
To: nathan@webr3.org
CC: Tim Berners-Lee <timbl@w3.org>, TAG List <www-tag@w3.org>
An additional wrinkle... working through Python httplib.Connection, I note that 
redirection (for 301) is handled transparently for GET but not for POST, PUT or 
DELETE operations.

Similarly when working with Python urllib2.

#g
--


Nathan wrote:
> Tim Berners-Lee wrote:
>> Looking at my action item to characterize the deductions made from 
>> HTTP responses in the tabulator library, I found these related questions:
>>
>> 1) If A redirects 301 "Moved" to B, what should be the XML base which 
>> is used to parse the representation returned from B?
>>
>> 2) If A redirects 302 "Found" to B, what should be the XML base which 
>> is used to parse the representation returned from B?
>>
>> I assume everybody parses with B as the base.
>>
>> One could make an argument that in the Found case, the original URI is 
>> the one everyone should use for the document, and so any 
>> self-reference ought also to apply to A, which is best served by 
>> Example:  a canonical place for an ontology is redirected Found to a 
>> SVN store where the current version of the ontology file is. That file 
>> says    in N3  <> dc:title "This is an ontology which...".
>>
>> What do people thing about (a) logic and (b) current practice?
> 
> Regarding (b):
> 
> The short version is that most of the time only URI A is known, and any 
> redirected-to URIs are hidden within blackbox client libs; the common 
> approach is:
> 
>   uri = 'http://...';
>   doc = get(uri);
>   dom = parse(doc,uri);
> 
> Where get is a method which follows redirects, thus the true Location of 
> the document is often unconsidered and the URI used as base is that 
> which was requested.
> 
> I've checked XMLHttpRequest by setting xhr.followRedirects = true;
> 
> The results for 1) /foo => 301 /nathan are:
> 
>  xhr.responseXML.URL = "http://webr3.org/foo";
>  xhr.responseXML.baseURI = "http://webr3.org/foo";
>  xhr.responseXML.documentURI = "http://webr3.org/foo";
> 
> The results for 2) /bar => 302 /nathan are:
> 
>  xhr.responseXML.URL = "http://webr3.org/bar";
>  xhr.responseXML.baseURI = "http://webr3.org/bar";
>  xhr.responseXML.documentURI = "http://webr3.org/bar";
> 
> In fact it goes one further, I actually couldn't find any way to get the 
> redirected-to URI (/nathan) back out from XHR - it's completely hidden.
> 
> This is also the case for many (most) server side HTTP clients which 
> follow redirects.
> 
> Thus in most cases, the only URI known is that which was originally 
> requested.
> 
> The only common exception I know is that for 2xx responses which have 
> been conneg'd, then the Content-Location header is exposed on request, 
> but again it isn't used at all.
> 
> Best,
> 
> Nathan
> 
Received on Tuesday, 26 October 2010 17:56:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:28 GMT