Closed Bug 86835 Opened 24 years ago Closed 23 years ago

[FIX]Can't view source of dll cgi

Categories

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

Product:
Core Graveyard
Component:
View Source
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.1alpha

People

(Reporter: BenB, Assigned: bzbarsky)

References

(
URL
)

Details

Attachments

(2 files)

screenshot of download dialog that comes up for this URL, linux, currrent trunk build.
(deleted), image/jpeg
Details
The "hacky" patch
(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
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?
Attached patch The "hacky" patch (deleted) — — Splinter Review
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: 23 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.

Attachment

General

Creator:
Created:
Updated:
Size: