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)
Core
Networking: HTTP
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.
Comment 1•24 years ago
|
||
I thought we had a loop detection algorithm?
See also bug 46115 for a reason why we may not detect redirection loops.
Comment 2•24 years ago
|
||
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?
Assignee | ||
Comment 4•24 years ago
|
||
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.
Comment 5•24 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•