W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [XHR] Redirects

From: James Leigh <james-nospam@leighnet.ca>
Date: Tue, 14 Sep 2010 13:22:30 -0400
To: Darin Fisher <darin@chromium.org>
Cc: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
Message-ID: <1284484950.1829.20.camel@james-laptop>
On Tue, 2010-09-14 at 09:55 -0700, Darin Fisher wrote:
> On Mon, Sep 13, 2010 at 7:35 AM, Anne van Kesteren <annevk@opera.com>
> wrote:
>         On Wed, 01 Sep 2010 23:59:17 +0200, Darin Fisher
>         <darin@chromium.org> wrote:
>         
>                 On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren
>                 <annevk@opera.com> wrote:
>                 
>                         That seems like the current design, except we
>                         currently do not have that
>                         additional method. I would like to keep it out
>                         until it is more clear this
>                         is a real problem. It would add quite a bit of
>                         complexity whereas just
>                         having this is fairly straightforward.
>                 
>                 The problems I've raised here are real problems that
>                 I've observed while
>                 building HTTP implementations for Mozilla and
>                 Chromium.  It is easy for good coders to make these
>                 kinds of mistakes.
>                 
>         
>         I did not mean to downplay the problems you were raising. Do
>         you think we should have a method like openPreserveState()
>         that unlike open() does not reset a bunch of information? So
>         to handle a redirect you would do openPreserveState(); send();
>         after the initial request if status is one of 301/302/303/307.
>         (You might have to do some more.)
> 
> 
> That's a very interesting idea.  Maybe it should be more specific,
> like openRedirectedLocation?  That said, if one still has to
> call .send() afterwards, then we are still leaving it up to the caller
> to pass the right value to .send().  They have to know when the method
> is being changed from POST to GET and take appropriate action.  That
> is a bit unfortunate.  Maybe .send() and .openPreserveState() could
> just be combined into a single .followRedirect() method?
> 
> 
>  

A challenge with having these methods combined is that it prevents the
caller from changing (or preserving) the request header between
redirects (Mozilla, for example, resets all its headers following a
redirect). By keeping them separate the caller can reinstate
non-standard (or standard) headers between redirects as necessary.

Thanks,
James
Received on Tuesday, 14 September 2010 17:23:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT