Closed Bug 803038 Opened 9 years ago Closed 9 years ago

Can't view source of files with attachment disposition


(Core :: Networking, defect)

Windows XP
Not set





(Reporter: neil, Assigned: neil)



(Keywords: regression)


(1 file)

For some strange reason, is served with a content disposition of attachment, which means that you can't just load it in to the browser. You used to be able to view its source by prefixing view-source: to the URL, but this no longer works. Instead, you still get prompted to download the file, and also the tab never stops loading. (In the case where you load it directly, the tab does stop loading.)

Unfortunately as I don't have any intermediate builds handy, all I know is that it works in Gecko 2 but not Gecko 11.
It's a bit odd that it ever worked, since I'd expect view-source channels to expose the underlying content disposition.

In any case, manual loading of view-source type things is really not supported.  The right way to handle this sort of case is to actually implement "view in browser" as a handling option...
Closed: 9 years ago
Resolution: --- → WONTFIX
I'm just glad I didn't get a JavaScript error in that script. It would have looked odd to click on the link in the Error Console and get prompted to download the script...
Oh, hmm.  If _that_ happens that would be a bug for sure.

Are you willing to hunt down the regression range on this?
I've bisected it down to 23 changesets, of which bug 589292 looks the most suspicious.
Blocks: 589292
Ah, yes.  Looks like nsViewSourceChannel QIs to nsIHttpChannel but sanitizes the list of headers it hands out.  "Content-Disposition" is NOT in the whitelist.  But bug 589292 made it hand out the underlying channel's content disposition.

Neil, does just stubbing out the content disposition and filename getters/setters on nsViewSourceChannel fix this for you?
Component: Document Navigation → Networking
Resolution: WONTFIX → ---
Attached patch Proposed patchSplinter Review
This patch fixes it for me, I just copied the style from the wyciwig channel, and then noticed that the idl says to return that nsresult anyway.

(I have since verified that the regression changeset was from bug 589292.)
Assignee: nobody → neil
Attachment #673195 - Flags: review?(cbiesinger)
Comment on attachment 673195 [details] [diff] [review]
Proposed patch

Attachment #673195 - Flags: review?(cbiesinger) → review+
Comment on attachment 673195 [details] [diff] [review]
Proposed patch

Review of attachment 673195 [details] [diff] [review]:

Perhaps add comments why you're not forwarding these calls to the underlying channel?

I'd probably keep the filename ones, just in case someone wants to save the file from view-source
Attachment #673195 - Flags: review+

(In reply to Christian Biesinger from comment #8)
> I'd probably keep the filename ones, just in case someone wants to save the
> file from view-source
If only it was that easy :-(

Should this have a test?
Closed: 9 years ago9 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.