On Tue, 2010-09-14 at 09:55 -0700, Darin Fisher wrote: > On Mon, Sep 13, 2010 at 7:35 AM, Anne van Kesteren <ann...@opera.com> > wrote: > On Wed, 01 Sep 2010 23:59:17 +0200, Darin Fisher > <da...@chromium.org> wrote: > > On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren > <ann...@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
