If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Generated pdf files served from "RenderPDF.aspx" script on sever saved as "RenderPDF.aspx" despite application/pdf content-type

RESOLVED DUPLICATE of bug 416094

Status

Core Graveyard
File Handling
RESOLVED DUPLICATE of bug 416094
7 years ago
a year ago

People

(Reporter: Dom Mellon, Unassigned)

Tracking

({helpwanted, student-project})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.2.10pre) Gecko/20100829 Camino/2.1a1pre (like Firefox/3.6.10pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en; rv:1.9.2.10pre) Gecko/20100829 Camino/2.1a1pre (like Firefox/3.6.10pre)

I received an email with links to my rail 'e-tickets' which I had previously purchased.  An example URl is below:

http://www.buytickets.crosscountrytrains.co.uk/RenderPDF.aspx?Mjc2MTEzNzkwdGlzc2lwRU1BSUxTZWNyZXRLRVlGb3JCb29raW5nSUQ=

(The render is time sensitive and may not work if you try to open it).

Camino is my default web browser.

Clicking on the link in Apple mail causes Camino to download a file named RenderPDF.aspx and not the generated pdf file it is supposed to download.  Copying the link location in Apple Mail and pasting it into an alternative browser (i.e. Google Chrome) results in the pdf file being downloaded and displayed properly.  



Reproducible: Always

Steps to Reproduce:
1.Open email with links to generated pdf
2.Follow link
Actual Results:  
File downloaded named RenderPDF.aspx (unusable)

Expected Results:  
Expected to download generated pdf file with e-ticket information

Expected resulted achieved by following link in alternative browser.
What happens in Safari is that WebKit's internal PDF rendering displays the PDF; Chrome doesn't appear to have PDF support, so it just downloads the RenderPDF.aspx and gives it a .pdf extension.

Camino and Firefox (without a PDF plug-in, like PDF Browser Plugin) will download the file, but for some reason Gecko is preferring the filename extension (.aspx) over the content-type (application/pdf), so the filename extension doesn't get changed on the download.  I'm not positive this is really a bug per se/per spec.

However, the file that is downloaded is in fact your e-ticket PDF; simply renaming "RenderPDF.aspx" to "RenderPDF.aspx.pdf" in the Finder lets Preview or other PDF viewers open the file.

(Ideally the server would be better-configured and would supply a filename ending in .pdf, and a content-disposition=attachment or something, which would likely make Gecko apps use the provided filename.)
Summary: Error downloading generated pdf files from website following link in email (Apple Mail/Camino) → Generated pdf files served from "RenderPDF.aspx" script on sever saved as "RenderPDF.aspx" despite application/pdf content-type
Created attachment 472770 [details]
LiveHTTP headers from loading the URL in Firefox 3.6.10pre

Given that the file is going to go away, here is the file "load" in Firefox 3.6.10pre captured by LiveHTTPHeaders, in case this is a bug.

Comment 3

7 years ago
Dom, you can e-mail the server administrators and tell them about the last paragraph of comment 1 if you want. That's probably the best way to "fix" this, as I'm also not really sure this is a browser bug.

cl
Hardware: x86_64 → All
Boris, can you or someone comment on whether this is actually a bug?

That is, given the set of HTTP headers in comment 2 (including an application/pdf content-type, but not a filename or content-disposition), and the fact that the script? loading the file has a .aspx extension, and in the absence of a PDF-handing plug-in, Gecko downloads a PDF file that it names "RenderPDF.aspx".

I poked through the File Handling bugs and didn't see anything that seemed like it was specifically this, where "file's" extension ≠ extension for the content-type, so it doesn't seem like a dupe, but that doesn't automatically make this a bug, either.
So we're talking the codepath that happens when someone clicks a link, not when using "save link as", right?

In that situation we only use the type-derived extension, I believe, when opening in a helper app on Windows.  In other cases we use whatever filename we got from the headers or url.

Though embedders can override at least from the helper app dialog by doing their own thing with filenames before calling SaveToDisk.  If you're not going through that dialog (e.g have "never ask" for that type set), then you get the default behavior.

I'm sure we've had bugs about this before.  Maybe we should expand our type-derived extension usage (or better yet, make it look like the much more sophisticated "save as" codepaths).
(In reply to comment #5)
> So we're talking the codepath that happens when someone clicks a link, not when
> using "save link as", right?

Right.

> In that situation we only use the type-derived extension, I believe, when
> opening in a helper app on Windows.  In other cases we use whatever filename we
> got from the headers or url.

Which means that since there's no filename in the headers in this case, we're getting the ".aspx" that's part of the URL.

> Though embedders can override at least from the helper app dialog by doing
> their own thing with filenames before calling SaveToDisk.  If you're not going
> through that dialog (e.g have "never ask" for that type set), then you get the
> default behavior.

In Camino we use "never ask" and there's no UI to select the "ask" codepath ("ask" works, but it's not fleshed out like our "Save As" code), so, yeah, we're just getting the default Gecko-provided filename.

> I'm sure we've had bugs about this before.  Maybe we should expand our
> type-derived extension usage (or better yet, make it look like the much more
> sophisticated "save as" codepaths).

That sounds good to me, particularly for cases like this where the extension in the URL and the content-type are clearly mismatched.  Should we move this bug (to Core:File Handling?)?

And thanks again for the diagnosis help!
> Should we move this bug (to Core:File Handling?)?

Sure, but that's ... somewhat underowned right now.  Helpwanted!  I definitely don't have time to work on this.  :(
It's far beyond the level of things I can fix, and as much as this sort of thing makes us look bad against Safari and Chrome, we don't really have the manpower now to devote to fixing it, either :(
Severity: major → normal
Status: UNCONFIRMED → NEW
Component: Downloading → File Handling
Ever confirmed: true
Keywords: helpwanted
Product: Camino → Core
QA Contact: downloading → file-handling
For what it's worth, I do have the time to handhold someone a bit if they want to work on this.
Keywords: student-project

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 416094
(Assignee)

Updated

a year ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.