- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 16 Sep 2010 15:31:43 +0200
- To: Anne van Kesteren <annevk@opera.com>
- CC: Darin Fisher <darin@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, WebApps WG <public-webapps@w3.org>
On 16.09.2010 11:32, Anne van Kesteren wrote: > On Thu, 16 Sep 2010 09:50:41 +0200, Julian Reschke > <julian.reschke@gmx.de> wrote: >> If using followRedirect() is easy, but manually following it is hard, >> people might choose the wrong approach just because it's easier. > > Well, what is wrong and what is right is still an open issue in the HTTP > WG. Yes, that's <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160>. I note that there are servers out there that expect method name preservation upon 301/302 (such as Apache/moddav), and that there are clients out there that do this. I don't believe that we're going to make these cases non-compliant; maximally, we could state the special situation for POST (and just that, not all methods). >> I think that obtaining the resolved Location for the redirect is the >> most tricky part, and we should come up with a solution where that is >> also available for people who do not want the default browser behavior. > > I don't really like special casing the Location header here. It seems we > are ending up with two additional members for dealing with redirects. I > do not want another one. There are other headers where resolving a URL > might be needed. Adding a parameter to navigator.resolveURL() for a base > URL is the way to go I think. That sounds good to me. In general I think it would be great if there were standard APIs for URI/IRI construction, parsing and resolution... Best regards, Julian
Received on Thursday, 16 September 2010 13:32:23 UTC