Closed
Bug 86835
Opened 23 years ago
Closed 23 years ago
[FIX]Can't view source of dll cgi
Categories
(Core Graveyard :: View Source, defect, P1)
Core Graveyard
View Source
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.1alpha
People
(Reporter: BenB, Assigned: bzbarsky)
References
()
Details
Attachments
(2 files)
(deleted),
image/jpeg
|
Details | |
(deleted),
patch
|
bbaetz
:
review+
rpotts
:
superreview+
|
Details | Diff | Splinter Review |
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
Comment 2•23 years ago
|
||
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
Assignee | ||
Comment 4•23 years ago
|
||
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.
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.3 → Future
Comment 5•23 years ago
|
||
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?
Comment 8•23 years ago
|
||
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
Reporter | ||
Comment 9•23 years ago
|
||
Compare (fixed) bug 120113.
Comment 11•23 years ago
|
||
*** Bug 119711 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 12•23 years ago
|
||
*** Bug 110256 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 13•23 years ago
|
||
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.
Comment 14•23 years ago
|
||
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?
Assignee | ||
Comment 15•23 years ago
|
||
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"?
Assignee | ||
Comment 16•23 years ago
|
||
Rick, the patch is a simplistic implementation of what you suggest in bug 77337,
comment #30. What do you think of it?
Assignee | ||
Comment 17•23 years ago
|
||
*** Bug 135524 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 18•23 years ago
|
||
setting component to make this findable.
Component: XP Apps: GUI Features → ViewSource
Assignee | ||
Comment 19•23 years ago
|
||
*** Bug 144010 has been marked as a duplicate of this bug. ***
Comment 20•23 years ago
|
||
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+
Comment 21•23 years ago
|
||
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 ??
Assignee | ||
Comment 22•23 years ago
|
||
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 23•23 years ago
|
||
Comment on attachment 77158 [details] [diff] [review]
The "hacky" patch
eww. r=bbaetz
Attachment #77158 -
Flags: review+
Assignee | ||
Comment 24•23 years ago
|
||
checked in on the trunk. I doubt drivers would take this on the branch.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 25•23 years ago
|
||
*** Bug 147231 has been marked as a duplicate of this bug. ***
Comment 26•23 years ago
|
||
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?
Assignee | ||
Comment 27•23 years ago
|
||
That would be a very separate bug from this one.
Assignee | ||
Comment 28•22 years ago
|
||
*** Bug 92187 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•