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? > > Do you think I should comment out the followRedirects feature for now? At > until we address the problem of how to follow it easily? I don't have strong opinions about that. It is up to you. I think it is OK to iterate :) -Darin > > > > -- > Anne van Kesteren > http://annevankesteren.nl/ >
