- From: Darin Fisher <darin@chromium.org>
- Date: Wed, 1 Sep 2010 15:00:03 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
Received on Wednesday, 1 September 2010 22:00:37 UTC
On Wed, Sep 1, 2010 at 5:19 AM, Julian Reschke <julian.reschke@gmx.de>wrote: > On 01.09.2010 10:16, Anne van Kesteren wrote: > >> ... >> >> I thought of another reason to want the original XHR object to be >>> responsible for following the redirect: the value of a Location header >>> may be a relative URL. It would be nice if application authors did not >>> have to take care of resolving that manually. (In the case of a >>> cross-origin >>> request, the relative URL should be resolved relative to the URL that was >>> redirected instead of against the Document.) This seems like something >>> that could be easy to mess up. >>> >> >> Yeah, I thought of that. There's location.resolveURL(), but it does not >> take a base URL at the moment. We could add that. Though note that >> relative URLs are forbidden in theory. >> ... >> > > They are in RFC 2616, but not in HTTPbis (< > http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-11.html#rfc.section.9.4 > >). > > Best regards, Julian > What does it mean for them to not be part of HTTPbis? Relative URLs in Location headers are not uncommon. -Darin
Received on Wednesday, 1 September 2010 22:00:37 UTC