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
attached mail follows:
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
attached mail follows:
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
attached mail follows:
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
attached mail follows:
>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. > > ....RoyReceived on Friday, 25 July 1997 09:27:01 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:03 UTC