W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: Redirects

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Sat, 26 Jul 1997 22:02:27 -0700
To: Yaron Goland <yarong@microsoft.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9707262217.aa25640@paris.ics.uci.edu>
>>>The argument I have been making with Larry is that we should define a
>>>minimum number of redirects to be supported by a client but should not
>>>put a maximum on servers. A server may have a perfectly rational reason
>>>for wanting to exceed whatever limit we have placed on redirects.
>>>However, for the sake of interoperability, a server needs to know what
>>>is the maximum number of redirects a client is guaranteed to support.
>> 
>>Oh, that's a much easier question: the answer is zero.  You cannot force
>>a user agent to make a network request (because it may cost them money),
>>so you cannot guarantee that a client will perform a redirect without
>>first asking the user for confirmation.
>
>Roy, do you even understand why your response makes me upset? Was that
>your goal? To state the painfully obvious as if it was relevant to the
>point under consideration is just asinine. Clearly the user can stop any
>operation. That isn't the issue. The issue is how many times will the
>system even give the user a choice to stop the operation before it steps
>in and stops the redirections itself. Currently we have set that limit
>to 5. I do not believe that is appropriate. Rather I think we should set
>the minimum to 5. 

Sorry, if you want me to continue answering your questions, you should
make more effort to phrase them correctly and not get upset with me when
I answer what you actually asked instead of what you intended to ask.
I never was very good at ESP.

A lot of people seem to think that I have some duty to answer questions
about HTTP.  I don't.  Mostly I do so because I like helping other Web
developers, and other times because it is easier to answer the question
now than it is to work-around the resulting browser bug six months from now.
In any case, it costs me time, and that is the most valuable thing I don't
have right now.

>That the system will present the user at least 5 redirections before
>just saying "Something has gone wrong, there is an error, I am ending
>this operation." In cases where the redirection is automatic, then the
>system would only be required to automatically redirect up to five
>times. 

The spec doesn't require the agent to end the operation -- it only says
that it should pause and get user confirmation that it should continue,
rather than just blindly redirecting for eternity.  Whether or not the
number 5 is right is a valid question, but there needs to be at least
a note recommending that it be configurable.  In that sense, an
infinite number of redirects is currently "supported".

>BTW I am not asking for a UI requirement. It is completely appropriate
>for a browsers, in case of 302 on a POST or similar method, to never
>even present the redirect to the user for confirmation. This is
>certainly the case when running in batch mode, for example. However in
>cases where it is appropriate to present a dialog, at least five rounds
>of redirections should be supported. If the user wants to end the
>situation earlier than that, that is the user's prerogative.

But here is where you lose me.  A redirect is a new request, and therefore
subject to the requirement that the user be in control over whether or
not a new request is made.  It is therefore impossible for the protocol
to place any *minimum* on the number of redirects.  If that upsets you,
I'm sorry, but that is how it is in order to prevent unscrupulous or
idiotic sites (like pathfinder) from screwing people who pay for their
network access on a per-request or per-packet basis.  Likewise, an agent
like MOMspider will stop traversing the redirects as soon as they leave
the traversal space (usually bounded by some URL prefix).  Trying to make
a requirement for something that is so dependent on the context of the
usage is very hard with HTTP.

....Roy
Received on Saturday, 26 July 1997 22:38:59 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:49 EDT