Closed Bug 75177 Opened 24 years ago Closed 23 years ago

http 0.9 rendered as content-type: text/plain

Categories

(Core :: Networking: HTTP, defect, P4)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: mcrites, Assigned: jtaylor)

References

()

Details

(Keywords: dataloss)

Attachments

(2 files)

This page will not render well. Most of the page is missing. Thanks for any input.
*** Bug 75178 has been marked as a duplicate of this bug. ***
Fixed the URL: it is .com and not .org. Most of the page is blank fron content on my home made build from today too.
This page is really rendering bad.
Most of the page is shifted out to the right. You can scroll there. The reason seems to be an <EMBED> element (Flash) within an <OBJECT> element. If you remove that <EMBED>, the page looks well. Seems to be a dupe of 72427. *** This bug has been marked as a duplicate of 72427 ***
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Target Milestone: --- → mozilla0.9.2
shrir says this is not a dup, reopening.
shrir, can you develop a test case?
Assignee: asa → karnaze
Status: UNCONFIRMED → NEW
Component: Browser-General → Plug-ins
Ever confirmed: true
QA Contact: doronr → shrir
Only problem I see now: Ads are displayed as text/plain and not text/html. Note that ads1.ad-flow.com sends HTTP/0.9, i.e. no Content-Type. (2001-05-23-20, Win NT)
Reassigning to pollmann to deal with iframe issue.
Assignee: karnaze → pollmann
Keywords: dataloss
Here's the response from the server for the add. No server headers whatsoever. Even when typed into the URL bar, this is being displayed as text/plain: <CRLF> <CRLF> <a href="http://green:8002/ads1.ad-flow.com/?RC=7054&AI=482&RANDOM=96815384919365" target="_blank"><img src="http://green:8002/ads1.ad-flow.com/?AI=482&SN=7054&FN=AveA-buy-125-CPM-2&RANDOM=96815384919365&AN=Y" alt=" " height="125" width="125" border="0"><br>Great Deals!</a>
Assignee: pollmann → neeti
Component: Plug-ins → Networking: HTTP
OS: Linux → All
QA Contact: shrir → benc
Hardware: PC → All
Summary: Does not render well → http 0.9 rendered as content-type: text/plain
Sorry, that's supposed to be: (<CRLF> is a CR followed by LF, there is no trailing line break of any kind.) -------- Start of response -------- <CRLF> <CRLF> <a href="http://ads1.ad-flow.com/?RC=7054&AI=482&RANDOM=96815384919365" target="_blank"><img src="http://ads1.ad-flow.com/?AI=482&SN=7054&FN=AveA-buy-125-CPM-2&RANDOM=96815384919365&AN=Y" alt=" " height="125" width="125" border="0"><br>Great Deals!</a> -------- End of response -------- ...the green:8002 in the url was bad cut-and-paste by me... ;)
so our unknown content decoder is not picking up text/html correctly?
If that is the entire HTTP response, then the problem is that none of the tags that the UnknownContent decoder looks for are present :-( In order for the sniffer to work correctly, it would also need to look for <a> tags. I believe the old 4.x one did this... -- rick
only 0.9 based servers. Pushing until 0.9.3
Priority: -- → P4
Target Milestone: mozilla0.9.2 → mozilla0.9.3
*** Bug 85039 has been marked as a duplicate of this bug. ***
Keywords: nsenterprise
the html on this page is badly formed. it lacks a starting <html> or <body> tag. this makes it really hard on our unknown content decoder. perhaps we could make the unknown content decoder look for strings like "<a href" b/c otherwise i'm not sure how we'd detect the content on this page as text/html.
*** Bug 87912 has been marked as a duplicate of this bug. ***
I'm not sure if this is a text/plain problem. Please see my comments in Bug 87912
Scratch my previous comment about this not being a text/plain problem. But do see my comments in Bug 87912
*** Bug 90219 has been marked as a duplicate of this bug. ***
I am going to close this out for darin. His patch works. dougt: can you review?
Status: NEW → ASSIGNED
->jtaylor
Assignee: neeti → jtaylor
Status: ASSIGNED → NEW
look fine to me. r
*** Bug 91778 has been marked as a duplicate of this bug. ***
r=bbaetz, so if dougt's r counts as an sr, this can be checked in.
it does indeed. sr=me.
Fix checked in.
Status: NEW → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
Verified on Linux 2001090608
Verified on OSX and Win2000.
Status: RESOLVED → VERIFIED
QA Contact: benc → junruh
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: