Closed Bug 86835 Opened 19 years ago Closed 18 years ago

[FIX]Can't view source of dll cgi

Categories

(Core Graveyard :: View Source, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.1alpha

People

(Reporter: BenB, Assigned: bzbarsky)

References

()

Details

Attachments

(2 files)

Reproduction:
1. Visit <http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=1247292051>.
2. View Source

Actual result:
1. empty View Source window comes up
2. Download dialog comes up for 'dll' / application/x-msdownload
(3. If you confirm "default action", the page gets downloaded again, but won't
display)

Expected result:
Exactly the page I see in the browser gets displayed as source in View Source
window.
Happens on Linux 2001061914 too.
OS: Windows 95 → All
Hardware: PC → All
Priority: -- → P3
Target Milestone: --- → mozilla0.9.3
Looks like ebay doesn't send any content type, just:
HTTP/1.0 200 OK
Server: Microsoft-IIS/4.0
Date: Wed, 20 Jun 2001 17:30:05 GMT

But they send this at the beginning of the html:
<html>
<head>
<!--A http-equiv="Content-Type" content="text/html; charset=UTF-1-->
<meta http-equiv="Expires" content="Wed, 20 Jun 2001, 17:35:53 GMT">
<title>

Not sure why view source isn't just showing whatever it has, instead of trying
to redetect the content type...
-xpapps
Assignee: neeti → blake
Component: Networking: HTTP → XP Apps: GUI Features
QA Contact: benc → sairuh
Well.. View source is most likely reloading this URL from the server.  Because
we don't have view source properly using cache yet.  See bug 55583.  This is
probably a dup.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.3 → Future
Depends on: 55583
The problem is that the view-source probably doesn't look into the meta tags for
the content-type. I think that it should be marked as invalid, because the
Content-type should always be in the headers -> buggy server.
I don't know if the bug 55583 is relevant to this. Is the content-type modified
for cached entries when found in the meta http-equiv?
This should be fixed by any fix for bug 77337
Depends on: 77337
mass moving open bugs pertaining to view source to pmac@netscape.com as qa contact.

to find all bugspam pertaining to this, set your search string to
"ItsSharkeysNight".
QA Contact: sairuh → pmac
Compare (fixed) bug 120113.
-> doron
Assignee: blaker → doronr
Status: ASSIGNED → NEW
*** Bug 119711 has been marked as a duplicate of this bug. ***
*** Bug 110256 has been marked as a duplicate of this bug. ***
I have a fix for this in my tree but it's a gross hack at this stage....  I've
been trying to get rpotts to answer mail about it, but no luck yet.
well, what's the right way to fix this?  I'm not a big
fan of gross hacks if we can avoid them.  Note that one
of the dep bugs here got fixed, are we any closer now?
This seems like the best way to do this in the short run.

In the long run, the "correct" way to do this is to decide how the converter
service should generally handle options on mime types.	Should the handling be
uniform across converters or on a per-converter basis?	Should converters
register the full list of options they handle and all possible combinations
they handle? Or just set a flag that says "'foo/bar; options' is OK no matter
what the options are"?
Rick, the patch is a simplistic implementation of what you suggest in bug 77337,
comment #30.  What do you think of it?
*** Bug 135524 has been marked as a duplicate of this bug. ***
setting component to make this findable.
Component: XP Apps: GUI Features → ViewSource
*** Bug 144010 has been marked as a duplicate of this bug. ***
Comment on attachment 77158 [details] [diff] [review]
The "hacky" patch

sr=rpotts@netscape.com.

it's kinda hacky :-)  but it's the best we can do without reworking the
streamconverter service.
Attachment #77158 - Flags: superreview+
is there a bug to track the 'global issues' that the stream converter service is
not  parsing the content-type correctly and is too simplistic in the way it
chooses converters ??
Filed bug 144675.  Thanks for the sr!
Assignee: doron → bzbarsky
Priority: P3 → P1
Summary: Can't view source of dll cgi → [FIX]Can't view source of dll cgi
Target Milestone: Future → mozilla1.1alpha
Comment on attachment 77158 [details] [diff] [review]
The "hacky" patch

eww. r=bbaetz
Attachment #77158 - Flags: review+
checked in on the trunk.  I doubt drivers would take this on the branch.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
*** Bug 147231 has been marked as a duplicate of this bug. ***
This bug is not completely fixed - View Source works, but save source does not.
Not on the main page, and not on the File->Save Page As on the view source page.

Is there an existing bug for this? Should I file a new one, reopen this one?
That would be a very separate bug from this one.
*** Bug 92187 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
Product: SeaMonkey → Core Graveyard
You need to log in before you can comment on or make changes to this bug.