Closed Bug 66145 Opened 24 years ago Closed 24 years ago

Server can bounce Mozilla between two Moved Temporarily URLs

Categories

(Core :: Networking: HTTP, enhancement)

enhancement
Not set
normal

Tracking

()

VERIFIED INVALID

People

(Reporter: vectro, Assigned: darin.moz)

References

()

Details

BuildID: 2001010517 The URL example may not be valid for very long if efollett fixes their servers. :\ I'm not sure if this should even be considered a Mozilla bug, but it's something I feel should be considered for a workaround, to help Mozilla cope with a broken server. Envision a URL A. The server can direct the browser via a 302 moved temporarily to a URL B. Upon requesting URL B, the server can direct the browser back to URL A. In this case the browser will keep requesting one URL and then the other, in a seemingly infinate loop. Of course, the user can always hit STOP, and end this. This is consistant with the RFCs. So why am I making a bug report? It seems like it might not be a bad idea to let the user know when something like this happens - so the user can abort the transaction, rather than waiting a really long time, when nothing is likely to come of it. Currently, the user might just think the server is being slow to respond, as there's no indication of the 302 on the status bar.
I thought we had a loop detection algorithm? See also bug 46115 for a reason why we may not detect redirection loops.
I should add that I see no redirect loop with the url given using linux build 2001-01-18-08
Loops for me on 2001010517, and I see a loop doing raw HTTP/1.1 with the server. What do you see with the 2001-01-18 build?
We only attempt to detect redirects back to the same URL.. however, even our algorithm for this is flawed (ie. the URL in question could produce dynamic content). To properly detect the kind of redirect loop described here, we would have to maintain a list of URLs tracking the redirect chain. This list could only be used for entries with "static" content. That is, if an item in the chain could not be cached, then the chain would be broken. The 302 response is normally not cache-able... unless there is an Expires header or a Cache-control header. Therefore, in the case in which these headers are not specified, there would be no way to detect a redirect loop.
I see this as invalid. It's not really a Mozilla bug that deserves to be fixed. The problem lies in servers causing infinite loops. Thus is it is invalid. Reopen if I am wrong. In any case, it is better as invalid than unconfirmed :-)
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Verified invalid.
Status: RESOLVED → VERIFIED
QA Contact: tever → junruh
You need to log in before you can comment on or make changes to this bug.