- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 02 Sep 2010 00:24:17 +0200
- To: Darin Fisher <darin@chromium.org>
- CC: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
On 02.09.2010 00:00, Darin Fisher wrote: > On Wed, Sep 1, 2010 at 5:19 AM, Julian Reschke <julian.reschke@gmx.de > <mailto: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. Clarifying: they are *forbidden* in RFC 2616 (*), but not in HTTPbis (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics11.html#rfc.section.9.4>), so HTTPbis *allows* them now. BR, Julian (*) the ABNF doesn't allow them.
Received on Wednesday, 1 September 2010 22:24:59 UTC