Closed Bug 65550 Opened 25 years ago Closed 24 years ago

malformed HTML content without a "Content-Type" header displayed as text/plain

Categories

(Tech Evangelism Graveyard :: English US, defect)

Product:
Tech Evangelism Graveyard
Component:
English US
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: oseberg, Assigned: bugs4hj)

References

(
URL
)

Details

(Whiteboard: http://rateme.reactor-core.org/banners/net-on.html)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20010112 BuildID: 2001011204 I don't know what these banner guys are doing, but for some reason their code works for IE 5.00.2314.1003, Netscape Navigator 4.08, Opera 5.01 on Windows NT 4.00.1381 Reproducible: Always Steps to Reproduce: Go to the URL http://rateme.reactor-core.org/banners/net-on.html or use the html code <table width=468 height=60 border=0 cellspacing=0 cellpadding=0> <tr> <td> <iframe src="http://nbe.net-on.net/dserve.cgi?48505:11355:001" width=468 height=60 marginwidth=0 marginheight=0 hspace=0 vspace=0 frameborder=0 scrolling="no" id="adid" name="adname"> <a href="http://nbe.net-on.net/click.cgi?48505:11355:001" target="_top" onMouseOver="window.status='Ad delivered by Net-On! www.net-on.net'; return true"> <img width=468 height=60 border=0 hspace=0 vspace=0 alt="Click here" src="http://nbe.net-on.net/bserve.cgi?48505:11355:001"></a> </iframe> </td> </tr> <tr> <td align="center"> <font size=-2> <a href="http://www.net-on.net" target="_top">Ad delivered by Net-On! www.net-on.net</a> </font> </td> </tr> </table>
i think http://nbe.net-on.net/dserve.cgi?48505:11355:001 is the problem, and i hope that it's an illegal uri/url
Assignee: asa → braden
URL: http://rateme.reactor-core.org/banner... → http://nbe.net-on.net/dserve.cgi?4850...
Component: Browser-General → Networking
Whiteboard: http://rateme.reactor-core.org/banners/net-on.html
I'm not sure what an iframe is, but that URL returns the code: <A HREF="http://adtracking.net-on.net/click.cgi?48505:11355:001" target="_top"> <IMG SRC="http://adtracking.net-on.net/sys/plug?1&231" BORDER=0></A> when typed into Mozilla. When typed into the URL section for Netscape, IE, and Opera, it actually displayes the banner. So, it's probably actually the code above that's the problem. Both the URLs: http://adtracking.net-on.net/click.cgi?48505:11355:001 & http://adtracking.net-on.net/sys/plug?1&231 appear to work fine in Mozialla. The first sends you to the site owned by the banner ad, and the second shows the image for the banner ad.
It seems to be an error in dserve.cgi. Note: this bannersystem is just updated to version 3.1!
I created two pages with the code that I suspected: http://rateme.reactor-core.org/broken/net-on1.html http://rateme.reactor-core.org/broken/net-on2.html The first one with just that code, and the second one with <html><head>.... **** in it. Both appear to work fine with Mozilla. ( -> ) I sent. ( <- ) I got. ************************************** Fetching the file from my server. % telnet rateme.reactor-core.org 80 ->GET /broken/net-on1.html HTTP/1.1 ->Host: rateme.reactor-core.org -> <-HTTP/1.1 200 OK <-Date: Tue, 16 Jan 2001 03:57:16 GMT <-Server: Apache/1.3.12 (Unix) mod_perl/1.24 PHP/3.0.14 mod_ssl/2.6.6 OpenSSL/0.9.5a <-Last-Modified: Tue, 16 Jan 2001 03:49:55 GMT <-ETag: "1ccb85-95-3a63c4e3" <-Accept-Ranges: bytes <-Content-Length: 149 <-Content-Type: text/html <- <-<A HREF="http://adtracking.net-on.net/click.cgi?48505:11355:001" target="_top"> <-<IMG SRC="http://adtracking.net-on.net/sys/plug?1&231" BORDER=0></A> ************************************** Fetching the file from my server. % telnet nbe.net-on.net 80 ->GET /dserve.cgi?48505:11355:001 HTTP/1.1 ->Host: nbe.net-on.net -> <-HTTP/1.0 200 OK <-Date: Tue, 17 Jan 2001 03:54:32 GMT <-Server: Edge/3.0 (Unix) (Alpha) <-Content-Length: 154 <-Set-Cookie: T=X;domain=.net-on.net;path=/;expires=Tue, 01-Jan-2033 00:00:01 GMT <-Connection: close <-Cache-Control: private, max-age=0, no-cache <- <-<A HREF="http://adtracking.net-on.net/click.cgi?48505:11355:001" target="_top">< <-IMG SRC="http://adtracking.net-on.net/sys/banner?11035&234" BORDER=0></A> **************************************************************** I don't have a clue why it works from my server, but not theirs.
note: if you replace dserve.cgi with bserve.cgi it works!
Ok. Then I tried this: % telnet nbe.net-on.net 80 ->GET /bserve.cgi?48505:11355:001 HTTP/1.1 ->Host: nbe.net-on.net -> <-HTTP/1.0 302 Found <-Date: Tue, 17 Jan 2001 04:10:58 GMT <-Server: Edge/3.0 (Unix) (Alpha) <-Set-Cookie: T=X;domain=.net-on.net;path=/;expires=Tue, 01-Jan-2033 00:00:01 GMT <-Location: http://adtracking.net-on.net/sys/plug?1&234 <-Connection: close <-Cache-Control: private, max-age=0, no-cache <-Content-Type: text/html <- <-<HTML><HEAD> <-<TITLE>302 Found</TITLE> <-</HEAD><BODY><H1>The page has moved</H1></BODY></HTML> ********************************************************* Because of the Location: tag, I then tried: http://adtracking.net-on.net/sys/plug?1&234 in the URL for Mozilla, and that's what works. I guess that there must be differences in the way that Netscape, IE, and Opera are behaving for this banner ad, and therefor they have several different mechanisms to deal with those browsers. The problem must be that somehow Mozilla is causing this banner exchange software to choose a method that is incompatible with Mozilla. But I don't know enough about the internals of Mozilla and what mozilla supports to know what the problem is. Also, it appears that the header sent by my server works, and the header sent by their server doesn't work for the oringial: <A HREF="http://adtracking.net-on.net/click.cgi?48505:11355:001" target="_top"> <IMG SRC="http://adtracking.net-on.net/sys/banner?11035&234" BORDER=0></A>
Ahhh, their http header has no, "Content-Type:" section. Maybe that's the problem. Maybe when there's no content type section in the header the other browsers assume text/html and Mozilla doesn't? I'll try writing a quick server when I get home to check.
Yep, that's it
Ok, If that's the problem, should Mozilla be fixed so that it also assumes text/html when the header is missing the content type? Or should all the old servers out there who don't give out the content type when the type is text/html be upgraded and fixed?
Did you set pref("network.http.version", "1.0"); or do you use the default pref("network.http.version", "1.1"); ?? b.t.w. your server is using http 1.1 and there server is using http 1.0
1) There is a UI pref for this under Preferences|Debug|Networking 2) This is really an evangelism bug, but maybe we can make an exception for this. Maybe it's even in the works? Component looks correct, maybe you guys have an idea if this is really mozilla's fault. Leaving unconfirmed until we get an answer.
Why is this bug assigned to me?
I send net-on.com an e-mail about this problem. And I got a response from Andreas (net-on.com) they will take a look at it a.s.a.p. Just looked at some HTTP RFC's too and it looks like a bad response from there server! For now, we just have to wait on further actions from Andreas (net-on.com). He's aware of this problem, they just upgraded there server and cgi's scripts. Reporter, for how long do you use there service?
Reassigning to nobody@mozilla.org
Assignee: braden → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
Just signed up for it a few days ago.
Basically I'm worried about Mozilla. See, when I try something, and it works in all the browsers I can find except one, my first assumption is that that one browser is broken. It doesn't matter if the problem is with the server or some CGI not being complient. Cause my first impression (and everyone elses) is that the browser that doesn't work while all the rest do is a browser that sucks. I don't want people to think that Mozilla sucks. So, if there are other servers out there that cause this same problem, I believe that it is much less work to just modify Mozilla to solve the problem rather than all those servers out there. It is my hope that although this bug is low priority and can easily be fixed by my banner exchange with enough effort on my part that the people of Mozilla will take note of this message and realize that a good browser in the eyes of the users is not the one that is 100% compliant with the RFC's, but the one that behaves as expected more than any other browser. Because people have created servers and services that work with the pre-existing browsers, it is better to make a new browser work with those pre-existing browsers than to make it 100% compatible with some imaginary server that is 100% RFC complient. I want Mozilla to be the best browser possible.
Updating summary to reflect the real problem with this bug. Comments on further triage of this bug. This is not a duplicate of bug 18255, since there _are_ headers present. Mozilla _does_ attempt to autodetect HTML documents (bug 22321 implemented this), but the document in question not only does not have a "Content-Type" header but also has no <!DOCTYPE> and no <html> and no <body>. So it's not completely surprising that the autodetection detects it as text/plain. Assigning this to valeski, who handled both the other content-type bugs.
Assignee: nobody → valeski
Summary: Some sort of iframe problem → malformed HTML content without a "Content-Type" header displayed as text/plain
Boris nice catch those two bugs. This one is closely related to bug 22321. But then, that bug is fixed, so this bug must be sort of exception. Reporter, the fact that this works on your server, and not on there server, makes it very suspicious to me, don't you agree? And I'm not aware of any other, just upgraded, servers with the same problem!
note: "I don't want people to think that Mozilla sucks." that's the main reason I took action right away and did send then an e-mail! So don't worry, this will be fixed, here or at least by net-on!
H-J, You know what? Thanks.
I believe that the proper way to fix this bug is to assume that the content type is what the code pointing to it says. IE: <img src="junk"> (Junk is obviously an image even if the content type says it's not. If it's not recognizable as an image, then it's an error) Therefor: <iframe src="http://nbe.net-on.net/dserve.cgi?48505:11355:001"> would mean that, "http://nbe.net-on.net/dserve.cgi?48505:11355:001" must be text/html
As stated by Boris on 1/16 Mozilla will detect HTML if any one of three common (and standard) conventions are used. 1) The server send it as "Content-type: text/html" 2) A <!DOCTYPE> tag is used 3) An <HTML> tag is used This server/page ignores all three of those conventions. This is definantely not a bug in Mozilla. Also, an IFRAME can contain any kind of data, not just HTML. Assuming plain text if nothing else is specified is perfectly acceptable. This is not a bug in Mozilla. Moving to Evangelism. Also, assigning to H-J as per the comment on 1/16 an e-mail has already been sent.
Assignee: valeski → bugs4hj
Component: Networking → Evangelism
First accepting, and secondly this is the replay of Net-on: Thank you! We are very grateful for your help. We will take a look at this and try to fix this problem as soon as possible. Best Regards /Andreas, Net-on!
fixed
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for details.
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified
verified
Status: RESOLVED → VERIFIED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.