212208 - "document contains no data" error when handling HTTP/1.1 301 responses generated by WebSTAR (Mac OS9 Web server)

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Ben]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624

The problem occurs when attempting to accessing pages hosted on Mac OS 9 servers
running WebSTAR 4.3.

Specifically, URLs that end with a directory name and no trailing slash
consistently trigger a "document contains no data" error in Mozilla 1.4. For
example:

http://www2.edserv.musc.edu/mozilla_test

Problem occurs with the Mozilla 1.4 Win32 and OSX binaries released June 30,
2003. Problem was not present in at least two prior versions (1.01 for OSX and
1.2.1 for Windows). Other browsers (Netscape Communicator, IE, Safari, Opera) do
not exhibit the problem.

I have an HTTP log for the problem and will atttach it later (I'm using bugzilla
helper and don't see that option right now).

The problem seems to occur while handling 'HTTP/1.1 301 Moved Permanently'
responses from the server. Adding a trailing slash to the URL eliminates the
error -- possibly because it avoids the 301 response?

In case it matters, the servers and clients I am testing with do not have a
firewall between them (but all are behind a firewall). No proxies are involved. 

Reproducible: Always

Steps to Reproduce:
1. Start Mozilla 1.4
2. Access http://www2.edserv.musc.edu/mozilla_test (no trailing slash) OR any
other URL that references a WebSTAR host and ends in a directory name and no
trailing slash

Actual Results:  
After a delay of several seconds, "Document contains no data" error message is
displayed. Default page is not displayed.

Expected Results:  
Display default page:

http://www2.edserv.musc.edu/mozilla_test/

Adding the trailing slash as above works fine.


If I can do any additional tests to help isolate the problem, just let me know.

Comment 1

[Ben]

Attachment: HTTP log

Log generated using the July 9, 2003 nightly build for OSX

Comment 2

[Mats Palmgren (inactive)]

I think this is a duplicate of bug 77170.

Bug occurs when I have:
"Enable Keep Alive" on

Bug does not occur when I have:
"Enable Keep Alive" off

Comment 3

[Olivier Cahagne]

confirming comment 2 on Linux build 2003070405 (disabling keep-alive makes it
working).

Comment 4

[Darin Fisher]

this is a server bug.  the server is sends the following response:

  HTTP/1.1 301 Moved Permanently
  Location: http://www2.edserv.musc.edu/mozilla_test/

and then instead of gracefully closing the connection, it does a hard TCP reset.

i almost want to mark this bug as INVALID (since it is), but i see that IE6
manages to work around the problem.  so, we might want to look at trying to do
the same.  however, upon close inspection i see that IE6 has a much different
interation with the webserver.  in fact, for some reason IE6 appears to not
receive the TCP RST.  and for some reason, IE6 reuses the connection on which
the very same 301 response was delivered.  that is odd because that response can
only be terminated by the close of the connection by the server.  wierd!

Comment 5

[Darin Fisher]

reopening... i didn't mean to mark this bug invalid (yet).

Comment 6

[Olivier Cahagne]

Opera 7.11 on Linux loads the page too (with default settings).

Comment 7

[Ben]

Thanks for the comments and info, everyone.

I'm disabling persistent connections on the webserver hosting the previous test page. 
Test case is now located at:

http://edtest2.library.musc.edu/mozilla_test

Comment 8

[Andrew Schultz]

*** Bug 215672 has been marked as a duplicate of this bug. ***

Comment 9

[Andrew Schultz]

FWIW: this regressed between linux trunk 2003041508 and 2003041605, apparently
bug 84798

Comment 10

[Jo Hermans]

*** Bug 226373 has been marked as a duplicate of this bug. ***

Comment 11

[Jo Hermans]

bug 226373 contains a new testcase, and http-log

Comment 12

[Gary Davidson]

See Duplicate Bug Report # 226373.
With a fresh and independently discovered duplicate bug that also is fixed by
using the posted work-around by disabling Keep-Alives, isn't time for this 5
month old reported bug to be fixed in Mozilla V1.6 and the corresponding Netscape?  

This might be a more serious bug then originally reported in this bug report and
the duplicate bug report.  If a visitor goes to a website such as this test site
http://www2.edserv.musc.edu/mozilla_test and the site responses with an error,
that visitor would likely not know that their browser failed and it wasn't the
site that failed, and that visitor may never attempt to visit that site again. 
That is unacceptable when Internet Explorer, Mozilla 1.31 [and earlier versions]
and Netscape 6.0 [and earlier versions] all work.

Comment 13

[zaitcev]

I hit a similar situation with Hotmail. For some reason (maybe bugs in
the Hotmail, maybe bugs in Mozilla) browser accumulated a bunch of
cookies with ridiculous expiration times (January 18, 2038) for msn.com.
When going to MSN, Mozilla sends all cookies in the header. This does not
fit into one Ethernet packet, so kernel sends two packets. The server
replies with 302 Object Moved and RST, just like Darin described in
comment #4. This scenario does not happen if the HTTP headers fit
into a single packet.

In my case we have a bug in Microsoft IIS (yes, Hotmail has migrated)
where it gets confused by the continuation packet. However, it is
made visible by some mysterious cookie leak. The IE6 either does not
leak those cookies, or automatically expires cookies with ridiculous
expiration dates.

This probably has little to do with the keepalives as discussed in
the bug.

Comment 14

[Mikael Hedberg]

Still present in the Mozilla 1.7 and Firefox 0.9 series... This really needs to
be fixed ASAP now. People DO notice that "hey, this site doesnt work with
Mozilla, but it does with IE". That is *NOT* a good thing if you want people to
use these programs...

Even worse when it occurs in a situation (like one I just got reported to me)
when the site in question is the only point of contact between a person and an
organisation she needs to communicate with. Doesnt happen to everyone, but for
the people it does happen to it will severely damage their image of Mozilla's
quality.

Comment 15

[Darin Fisher]

dwitte: please take a look at comment #13 .. thanks!

Comment 16

[(not reading, please use [e-mail] instead)]

*** Bug 262518 has been marked as a duplicate of this bug. ***

Comment 17

[Hank Roberts]

Still happening with the latest OSX nightly, for me in this specific case:

Open any web page, hilight a block of text above some (screenful?) size, and 
click the "blog this" toolbar button (from blogger.com)

Using a smaller hilighted block, or carefully not including the end of the last 
paragraph (or end of table or frame? not sure) of the page text, avoids this.

There's an active thread in the Mozillazine Firefox Bugs forum, up to 4 pages 
now, with more discussion from people like me who aren't sure where to comment 
in Bugzilla.  I'm just guessing adding this comment here.

Comment 18

[Phil Ringnalda (:philor)]

*** Bug 271615 has been marked as a duplicate of this bug. ***

Comment 19

[Peter van der Woude [:Peter6]]

*** Bug 294830 has been marked as a duplicate of this bug. ***

Comment 20

[Darin Fisher]

-> default owner

Comment 21

[Matthias Versen [:Matti]]

This doesn't seem to happen anymore and the workaround from IE6 (comment#4) seems to be unnecessary