Closed Bug 75177 Opened 23 years ago Closed 23 years ago

http 0.9 rendered as content-type: text/plain

Categories

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

Product:
Core
Component:
Networking: HTTP
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: mcrites, Assigned: jtaylor)

References

(
URL
)

Details

(Keywords: dataloss)

Attachments

(2 files)

testcase to show 'blank space' inside Iframe problem
3.29 KB, text/html
Details
v1.0 fixes the problem by scanning for "<a href"
632 bytes, patch
Details | Diff | Splinter Review 
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.
URL: http://extremeoverclocking.org → http://www.extremeoverclocking.com
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: 23 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
URL: http://www.extremeoverclocking.com → http://green:8002/ads1.ad-flow.com/?D...
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: 23 years ago → 23 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

Creator:
Created:
Updated:
Size: