New Issue REDIRECTS

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:03 UTC

The following discussion has been going on privately, and needs
a wider audience.

I've assigned it the issue name REDIRECTS, and it will appear in
the next issues list page.
				- Jim Gettys

The HTTP spec says that redirects are to be limited to 5. We have found
this causes problems with some sites, like pathfinder. We tried 10 but
that didn't work particularly well either. So we currently have it set
for 100. Is there any particular reason why we desperately need to lower
that figure?
	Thanks,
		Yaron

Each redirect causes additional network traffic; the limit is there
to prevent an infinite loop causing infinite traffic to be generated.

I'd like to understand what PathFinder is trying to do to understand what
this limit might be lifted to.  There certainly needs to be some limit of
some sort.
				- Jim

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.

		Yaron

> -----Original Message-----
> From:	jg@pa.dec.com [SMTP:jg@pa.dec.com]
> Sent:	Tuesday, July 22, 1997 12:05 PM
> To:	Yaron Goland
> Cc:	Larry Masinter (E-mail); Roy T. Fielding (E-mail); Jim Gettys
> (E-mail)
> Subject:	Re: Redirects
> 
> Each redirect causes additional network traffic; the limit is there
> to prevent an infinite loop causing infinite traffic to be generated.
> 
> I'd like to understand what PathFinder is trying to do to understand
> what
> this limit might be lifted to.  There certainly needs to be some limit
> of
> some sort.
> 				- Jim

>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

Received: by src-mail.pa.dec.com; id AA13862; Fri, 25 Jul 97 01:48:46 -0700
Received: by pobox1.pa.dec.com; id AA22084; Fri, 25 Jul 97 01:48:44 -0700
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31])
	by mail2.digital.com (8.7.5/UNX 1.5/1.0/WV) with ESMTP id BAA17245
	for <jg@pa.dec.com>; Fri, 25 Jul 1997 01:43:11 -0700 (PDT)
Received: by mail5.microsoft.com with Internet Mail Service (5.0.1458.49)
	id <PSX6MBM9>; Fri, 25 Jul 1997 01:45:01 -0700
Message-Id: <11352BDEEB92CF119F3F00805F14F4850332A78F@RED-44-MSG.dns.microsoft.com>
From: Yaron Goland <yarong@microsoft.com>
To: "'Roy T. Fielding'" <fielding@kiwi.ics.uci.edu>,
        Yaron Goland
	 <yarong@microsoft.com>
Cc: "'jg@pa.dec.com'" <jg@pa.dec.com>,
        "Larry Masinter (E-mail)"
	 <masinter@parc.xerox.com>,
        "Jim Gettys (E-mail)" <jg@w3.org>
Subject: RE: Redirects 
Date: Fri, 25 Jul 1997 01:42:25 -0700
X-Priority: 3
X-Mailer: Internet Mail Service (5.0.1458.49)
X-UIDL: 6a4244389728a59ded607196a8bab141

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. 

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. 

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.

On to other issues, more as an editorial note. Some of the devs have not
clearly understood that 301/302 means "Re-execute the method you just
executed on this resource over on that resource." Some have thought, in
fact, that what is really meant is "Re-execute the following method on
this other resource" and wondered where the header was that specified
what method they should actually execute. For example, you could tell
someone doing a POST on resource A to instead do a PUT on resource B. I
realize you will all think these people to be drooling morons. They are
not. They are actually quite intelligent. The existence of their
misunderstanding indicates that what is implicitly implied in the text,
should instead be explicitly stated.

In fact there was a bit of a flap over a fear that 1.1 servers doing
301/302s would redirect the user to a 1.0 server w/a CGI script
expecting a GET. The problem is, that if a POST, on a 1.1 server, got
you the 302, you will execute another POST. Thus confusing the living
hell out of the target CGI. Then they made a number of proposals to deal
with the situation. My response was to say "HELL NO! If a server maker
is not aware of the effect of the responses they are generated, in this
case needing to generate a 303, then they are broken, screw 'em." Should
be interesting to see how that goes over.

			Yaron

> -----Original Message-----
> From:	Roy T. Fielding [SMTP:fielding@kiwi.ics.uci.edu]
> Sent:	Thursday, July 24, 1997 8:43 PM
> To:	Yaron Goland
> Cc:	'jg@pa.dec.com'; Larry Masinter (E-mail); Jim Gettys (E-mail)
> Subject:	Re: Redirects 
> 
> >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