Closed Bug 71653 Opened 23 years ago Closed 23 years ago

Simple example of 'hanging' on a HTTP redirect

Categories

(Core :: Networking: HTTP, defect)

defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 72348
mozilla0.9

People

(Reporter: jrgmorrison, Assigned: darin.moz)

References

()

Details

Overview Description: 

So, I don't know what I thought I saw when I responded to chofmann's note
about hanging on redirects.  I did set up something to redirect one of the
requests in the page loading test, but I thought that I wasn't seeing any
effect. (Actually, I'm pretty sure that at the time I didn't see any effect,
since this is one of those bugs that may come and go).

At any rate, last night, I tried it again, and it was getting hung up after
the 'Location:' redirect. When I applied it to all pages, I found that none of
them would cleanly close the http transfer.

I set up a simple example at http://jrgm.mcom.com/bugs/digitalcity/index.html,
which just provides (1) a normal link to the content for digitalcity.com, and
(2) a link that hits a cgi that gives a 'Location:' redirect.

On all three platforms, the direct link will load cleanly, but the redirect
will cause the throbber to continue spinning for ~17 seconds. I tried this
with current builds on Mac/Linux/win32, and with 03/06 on Mac, and 02/23 on
win2k, and they all show the same behaviour.

When I broke in an opt. debug build on win2k, the main (UI/layout) thread was
idle (at least to my naive eyes).

Steps to Reproduce: 
1) Go to http://jrgm.mcom.com/bugs/digitalcity/index.html
2) click on the first link on the page (a direct link)
3) hit back when that page has loaded, and then hit the second link on the
   page (a link to a redirect)

Actual Results:   throbber doesn't stop throbbing on the redirect
Expected Results: destination page should load normally

Reproducibility: 100% mac/win32/linux

Additional Information: 

The cgi is just this: 

  #!/usr/bin/perl
  my $loc  = 
   "Location:
http://jrgm.mcom.com/perf/loadtime5/base/www.digitalcity.com/index.html";
  print $loc, "\n\n";

The headers for the direct link are:

HTTP/1.1 200 OK
Date: Sun, 11 Mar 2001 09:24:01 GMT
Server: Apache/1.3.9 (Unix)  (Red Hat/Linux) mod_perl/1.21
Last-Modified: Sun, 07 Jan 2001 08:55:13 GMT
ETag: "7be8b-8d28-3a582ef1"
Accept-Ranges: bytes
Content-Length: 36136
Connection: close
Content-Type: text/html



The headers of the redirect are:

HTTP/1.1 302 Found
Date: Sun, 11 Mar 2001 09:25:37 GMT
Server: Apache/1.3.9 (Unix)  (Red Hat/Linux) mod_perl/1.21
Location: http://jrgm.mcom.com/perf/loadtime5/base/www.digitalcity.com/index.html
Connection: close
Content-Type: text/html
cool john,  thanks for putting some extra work on this.
I know that the older bug that identifies this problem
with many urls in the top 500 list in the weekly AOL
test run was marked "won't fix",  I really think we need 
to figure out a way to fix this.
I appreciate darin's point on bug 61693, that (if I understand it) it would
require a major change to deal with some of this. On the other hand, it 
seems that dealing with a redirect cleanly is the type of thing that has
to "just work" to be 'mozilla1.0', so it may be something that needs doing.
(Independent of AOL's testing needs, the user perception in this case is 
that the browser "doesn't work").
Blocks: 61693
Status: NEW → ASSIGNED
adding keyword nsbeta1
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9
Keywords: nsbeta1nsbeta1+
Blocks: 71668
Aha!  I don't have to report this one!  And it's not a bug with my proxy!  I
have seen this bug with both 301 and 302 redirects.  An easy way to see it is to
use my proxy: http://draal.physics.wisc.edu/FilterProxy/.  When mozilla gets a
redirect and sits there with the throbber continuing to spin, you can hit 'esc'
in mozilla, which causes it to close connections are pending.  Looking at
FilterProxy's logs, you can see which URL was last handled by that process, and
this occurs 100% of the time for 301 and 302 responses.

I don't know if it's relevant, but the example posted has an HTTP/1.1 connection
with the 'Connection: close' header.  With a 'Connection: keep-alive' header (as
used by my proxy) the throbber keeps spinning for about 2.5 minutes.  Note this
is less than the connection timeout as specified by the 'Keep-Alive' header.

Also note that recent builds  focibly close the connection after 1 request,
despite sending 'Connection: keep-alive' to the proxy.  However, the above
behavior still occurs.  This (1-connection-close) is in about the last week. 
Seen with 2001032015 and not with 2001021503, which is what I have lying around
on my disk.
Blocks: 39310
A new test case: http://www.jc-news.com/pc/ (this is temporary, I think
redirection will be abolished in a few days).
No content at all, message "Document Done" after 17 - 22.5 sec (isdn 64K).
darin said this is a dup of 72348
we're not able to reproduce the problem on my w2k box today. John, can you
verify if this is also working on other platforms?  Thanks!

*** This bug has been marked as a duplicate of 72348 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.