Closed Bug 18255 Opened 25 years ago Closed 25 years ago

No http headers sent, Nav assumes content-type: text/html?

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: tenney, Assigned: jud)

References

(
URL
)

Details

I am using build 98091517 on redhat(6.0) linux(2.2.13).  When you load the page
specified both frames show up empty.  If you look at the source it only shows
the body tags.  Both of these frames are being generated by CGI.  It works fine
in both navigator and IE.  I tried making some changes to get it to load with no
success.  Not sure whats causing it not to load.
Assignee: karnaze → pollmann
Reassigning to Eric.
Ok this doesn't seem to be a frame problem.  It appears to be a problem with any
CGI that I have running under mod_perl.  Any CGI thats not running under
mod_perl works fine.  Another example of the problem can be found here:

http://www.icebox.org/calendar/calendar?%2B=startup
Status: NEW → ASSIGNED
www.icebox.org doesn't appear to be putting out any http headers, just the
content of the html file.  When I cooked up a cgi manually that did the same
thing, but added this to it, things went ok:

Content-Type: text/html

Still not sure about the original test case...
Assignee: pollmann → warren
Status: ASSIGNED → NEW
Component: HTMLFrames → Necko
OS: Linux → All
Hardware: PC → All
Summary: Frames/HTML rendering problem → No http headers sent, Nav assumes content-type: text/html?
Same with the original test case, there are absolutely no http headers sent for
the frame documents:

This is what Nav and Gecko get:
pollmann blueviper(104):~/public/work/forms> telnet developer.digitalgreen.com
80
Trying 208.230.168.201...
Connected to cgi.digitalgreen.com.
Escape character is '^]'.
GET /call-bin/admin/login/login?page=init HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/4.7 [en] (X11; I; Linux 2.2.12-20 i686)
Host: developer.digitalgreen.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8

<META HTTP-EQUIV="expires" CONTENT="0">
<HTML><HEAD><TITLE>Call Scheduler Administration</TITLE></HEAD>
<BODY BGCOLOR="#FFFFFF">
...

Are we just supposed to assume what we are getting is HTML?  Nav seems to...
Oops, s/Gecko/Necko/g  :)
Assignee: warren → valeski
Jud: Looks like line 286 of nsHTTPChannel.cpp is the culprit. Can you switch it
to unknown. Thanks,
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
This is a not quite an issue of changing the default to "unknown" This will
not solve anything. The problem is that we search for two new lines together for
the end of headers. So in this case the data itself would be past these \n
chars (in this particular case that is the <BODY> tag) Unless the file has these
2 \n all of this is header stuff (which is quite correctly the right thing to
do) I believe what we are doing is right and the browser should not display this
HTML. By trying to accomodate these cases we will encourage people to write bad
HTTP cgi/servers. As for the reporter the correct fix is that you send at the
very least a content-type header. If you are using something like cgi-lib.pl
then its available as &PrintHeader. This will be the simplest way to
ensure your cgi works everywhere... Marking this as INVALID.
I agree w/ gagan. I just had to accomodate (for historical reasons :( ) for
multiple (\n\n, \r\n) "linefeed" cases in multipart/x-mixed-replace; it's not
pretty. This kind of header breaking delimiter is a clear violation of HTTP.
Status: RESOLVED → VERIFIED
Based on Judson's comments, marking as verified invalid.
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
You need to log in before you can comment on or make changes to this bug.