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.
[snip]
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.
Follow up, I've checked in various (latest public stable) browsers which
use XHR (where /A 3xx /B)
- Chrome only exposes "/A"
- Firefox only exposes "/B"
- Opera only exposes "/A"
All 3 only expose as part of the DOM Document in responseXML, thus it's
impossible to get "/B" for non DOM based (responseText) responses which
may also rely on knowing "/B" for processing / base requirements.
Would suggest that regardless of the TAG issue this needs clarified and
handled within the XHR spec and tests added (Anne van Kesteren suggested
this, also CC'd).
Best,
Nathan
