(crasher) Mishandling of HTTP "301-Permanently Moved" Responses

VERIFIED FIXED

Status

()

P3
major
VERIFIED FIXED
20 years ago
20 years ago

People

(Reporter: dirk.campbell, Assigned: troy)

Tracking

Trunk
Other
FreeBSD
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

20 years ago
Hi,

Browse to http://www.his.com/~peter.  You will be returned a message reading:

Netscape is out of memory.  Try quitting some other applications or closing
some windows.

As you can see from the following HTTP headers the GET request results
in a "301-(Site)Permanently Moved" response and redirection:


c:\wget - S http://www.his.com/~peter
--13:02:54--  http://www.his.com:80/~peter
            => `~peter'
Connecting to www.his.com:80... connected!
HTTP request sent, fetching headers...
1 HTTP/1.1 301 Moved Permanently
2 Date: Thu, 18 Mar 1999 21:01:13 GMT
3 Server: Apache/1.3.3 (Unix)
4 Location: http://www.his.com/~peter/
5 Connection: close
6 Content-Type: text/html
7
Location: http://www.his.com/~peter/ [following]
--13:02:54--  http://www.his.com:80/~peter/
            => `index.html.48'
Connecting to www.his.com:80... connected!
HTTP request sent, fetching headers...
1 HTTP/1.1 200 OK
2 Date: Thu, 18 Mar 1999 21:01:14 GMT
3 Server: Apache/1.3.3 (Unix)
4 Connection: close
5 Content-Type: text/html
6
     0K ->
 13:02:55 (845.70 KB/s) - `index.html.48' saved [866]

I have also verified this condition via a packet trace.

I'm actually trying to troubleshoot an issue with an ISP's customer.  I
understand that a response isn't generally returned here, but it would be
appreciated.

Thanks for your time.  Any questions, please ask.

Dirk Campbell
408-220-2200

Updated

20 years ago
Summary: 4.5 & 4.51 Mishandling of HTTP "301-Permanently Moved" Responses → Mishandling of HTTP "301-Permanently Moved" Responses

Comment 1

20 years ago
[Reproduced using 3.18.99 MacOS & Win32 builds of Seamonkey.]

Comment 2

20 years ago
[...which is why I suggested Dirk to submit it as a Seamonkey bug, even if he's
encountering it in 4.5, as well.]

Updated

20 years ago
Severity: normal → major
Summary: Mishandling of HTTP "301-Permanently Moved" Responses → (crasher) Mishandling of HTTP "301-Permanently Moved" Responses

Comment 3

20 years ago
[At risk of resembling a Burma Shave advertisement, I also note that this does in
fact crash Seamonkey immediately and reproducibly, rather than merely yield the
low memory error that Dirk encountered on 4.5 and 4.51.]

Updated

20 years ago
Assignee: rickg → gagan
Component: Parser → Networking Library

Comment 4

20 years ago
[And, finally, reassigning to gagan. ;-]

Updated

20 years ago
QA Contact: 3847 → 3819

Updated

20 years ago
Assignee: gagan → peterl
Component: Networking Library → Style System

Comment 5

20 years ago
It doesn't seem to indicate any problem with the 301 response. The "crash" is an
assertion failure from the nsCSSFramConstructor. So assigning to "style system"
owner...

Updated

20 years ago
Assignee: peterl → troy

Comment 6

20 years ago
This crashes in CantRenderReplacedElement. Over to you troy...
(Reporter)

Comment 7

20 years ago
This may or may not be pertinent .... FYI - in addition to experiencing this
phenomenon with 4.5 and 4.51 on an NT workstation, I also note an identical
occurrence using RedHat Linux 5.2 with Netscape 4.5.  Thx.
(Reporter)

Comment 8

20 years ago
This may or may not be pertinent .... FYI - in addition to experiencing this
phenomenon with 4.5 and 4.51 on an NT workstation, I also note an identical
occurrence using RedHat Linux 5.2 with Netscape 4.5.  Thx.
(Assignee)

Comment 9

20 years ago
Just so it's clear, it's hitting an assert. The assert is there so we catch the
function being used in a way that wasn't intented...
(Assignee)

Updated

20 years ago
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

20 years ago
Changed CantRenderReplacedElement() to handle APPLET tag as well

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 11

20 years ago
Marking verified, I don't see this crashing on 3/25 Linux builds. Dirk, please
speak up if you're still seeing it. Thanks.
You need to log in before you can comment on or make changes to this bug.