There are already ways to force browsers to download using HTTP headers. The author says this is a "server-side solutions to front-end problem", okay.
But anyways, when pages use this already, it OFTEN pisses me off, when I want to look at a PDF in browser, but the web app/page is forcing me to save it to disk and then re-open it in another app.
What we _really_ need, that we _don't_ have a way to do right now -- is signal the browser to _prompt_ the user as to whether it should be saved or displayed in-browser. The browser could ignore unless it was capable of displaying in-browser of course. That's something we do not have any way of doing in a reliable way now with HTTP headers, and I wish html5 would add that, instead of duplicating a lesser feature which is both possible now, and frequently annoying.
"Before the Chrome save button"? What does that even mean? Half the time I see people praising Chrome it's because of something thoroughly mundane, like an address bar, or saving files, or links. Did you guys browse the web using potatoes before you got Chrome, or what?
It means Chrome comes with a built-in pdf reader that, when you decide to save the file you're looking at, does not re-download it. This is significant when dealing with large files, and not a feature present in all competing products.
However, I would recommend re-downloading any pdf files instead of saving them from Chrome's reader, since I've encountered a couple that Chrome corrupted upon saving.
It seems kind of silly that certain browsers download it again. Isn't it stored as temp data somewhere? They should only have to rename it.
I'm actually happy with the way Chrome handles downloads in that it starts the download before you confirm if you want it, then deletes it should you decide you don't. It's cool clicking the "Download" link, navigating to the folder, renaming the file, and seeing the download is almost done.
Netscape (IIRC) would do another GET (or POST!?) when doing a view-source, which NEVEREVER made sense to anyone I would demonstrate it it. I want to see the source of the page that's currently rendered, not the source of another POST request. That behaviour thankfully seems not to be present in any modern browsers.
I may be misremembering, but didn't NN also re-GET on RESIZE EVENTS? I'm sure there was a very clever reason for doing so, but it sure did piss me off at the time.
I agree that the Acrobat plugin was a pain (and I always made sure to disable it in Firefox), but I absolutely love the Firefox in-browser PDF viewer. It doesn't lock up the PC while loading, and it has a convenient download button that doesn't seem to redownload the PDF when clicked (much like saving an already loaded image).
It might have something to do with my PC (i7 x220) but I cannot stand the Firefox viewer for anything but plain text. I find it very lacking in terms of performance compared to a native pdf viewer. Everytime a somewhat complex pdf opens up (mostly formulas, few images), the fan begins to rev up significantly..
Firefox's reader is an improvement over Adobe's, sure, but that's like beating snail in a foot race. Go Firefox, you show'em Chrome! It's still not SumatraPDF, it's not Evince. Saving the file and having it auto-open these programs takes less time then waiting for the browsers PDF readers to kick in. Of course it could be better, but frankly, I'd rather things be more unix'y, not less.
A major problem with saving all pdf files to be opened in a separate program is having to delete the temporary files afterwards. That's not very unix-y.
Another, less common, problem is erasing the URL in the process.
There are other readers in Windows (besides Window's 8 built in metro (full-screen) reader). Ever hear of Foxit http://www.foxitsoftware.com/Secure_PDF_Reader/ ? Mush much faster than Adobe Arobat.
It's funny how many Windows users seem to think the PDF format is intrinsically slow, and all because of Acrobat Reader. Safari on OS X renders a PDF just as quickly as any other webpage, and always has.
I imagine if you were to test that then the PDF rendering would actually be significantly faster than HTML, since OS X's rendering is all PostScript under the covers.
I've been using Sumatra for a long time, but it's been supplanted by Firefox in most cases recently. Sumatra is great and lightweight though, and it uses a robust and open source rendering and parsing engine.
That's cause you aren't actually looking at a PDF, most likely. If you are actually looking at a PDF in Chrome's renderer you will definitely be able to save it.
I'd also rather download and open in Sumatra but this is a handy feature I wasn't aware of. Opening the link in a new tab will not force the download (Chrome) unlike changing headers and masquerading the file as an application.
I would love to have an option in the right click menu to IGNORE the HTTP headers. For example, sometimes there is a link to an image like a jpg or a png that then forces you to download it. It REFUSES to ever render it in your browser. A right click option to ignore all MIME types and show it based on extention or magic bytes in the file would be AWESOME. Why do no browsers have that?
Content-Disposition attachement is one of the hardest things to implement when you have UTF-8 filenames. You have to browser sniff, and even then I have haven't found a good solution.
Does anyone know of a good resource that explains all the edge cases that must be handled?
See [1] for a very comprehensive and up-to-date table of browser support for various encoding schemes. See [2] for browser-specific hacks.
Summary: most modern browsers including IE9 support RFC2231/5987. (Edit: see my other comment in this thread for IE6-8.)
Another option is to leave out the troublesome "filename" parameter altogether and use the last part of the URL to convey the same information, e.g. /files/uploads/2013/<file_id>/filename.ext. After all, most browsers already understand how percent-encoding works in the URL. With today's URL rewriting engines, this shouldn't be too difficult to achieve regardless of how your files are actually organized on disk or which language you use to perform access control. It would be as if the client were requesting a static file.
Thanks. These days it looks like a reasonable solution is to just call the file "download.ext" for anything older than IE9.
When I was trying to implement a solution to this problem years ago, what I thought would take 20 minutes of coding, started to look like a week of research and testing, and I gave up.
In my experience, IE6-8 can handle UTF-8 filenames if (1) the extension is alphanumeric; (2) you percent-encode the rest of the filename, making sure that whitespace is encoded as "%20" rather than "+"; and (3) you put the whole thing between double quotes. Use RFC2231 for all other browsers, although slightly older versions of Chrome and Safari might cause trouble from time to time.
But nowadays I'm so comfortable with just using the URL that the above encoding schemes just feel like unnecessary hassle. HTTP was designed to display the filename in plain sight in the URL, not bury it in a header. Use it as intended and even IE will happily comply.
And of course it relies on the download attribute. So, okay, I guess the `download` attribute DOES make this possible with a bit of JS, where it wasn't before, okay, one step forward.
One nice feature of your solution is the user can still skip the prompt with a right-click or modifier-click 'save as' or 'open in new tab'.
Nicely done. I'm gonna use that in the future. To be more strictly legal, I'd use a `data-prompt="true"` attribute or something, instead of a not entirely legal made up 'prompt' attribute.
The security implication in this case is not directly related to content-disposition. It could just as well be implemented using the download attribute. The gist of the attack is that it was possible to inject arbitrary javascript into an html file that was downloaded. After opening the file locally, the usual browser protections do not apply since it's a local file and the javascript can use this to escalate its privileges.
Good point, but such a prompt would be similarly annoying (i.e. annoying to a similar number of users). The way I've done this in the past has been to provide two links, one of which triggered the inclusion of HTTP headers at the server, to trigger the Save dialo). Assuming the download attribute is supported, it's even easier:
> What we _really_ need, that we _don't_ have a way to do right now -- is signal the browser to _prompt_ the user as to whether it should be saved or displayed in-browser
Like "right-click and save-as"? I personally don't mind the small choice I get to make when downloading a file.
Right, some browsers do, some don't. (I used to be able to _get_ Firefox to, with the right config, but stopped being abel to figure out how, then switched to chrome where i haven't figured out how either).
But what we need is a standard cross-browser way to request this behavior (prompt for download vs show), that by default standards-compliant browsers will comply with (I'll allow for users over-riding this default behavior with configuration, if the browser wants to support that, sure).
We don't have that. I wish html5 would add that, instead of minorly improving an annoying thing we already have (way to signal the browser to force or default to download).
Sure, it should be avail in the HTML not just in HTTP headers, so the browser can let the signal effect it's UI before it does an http request for the asset, sure.
>But what we need is a standard cross-browser way to request this behavior (prompt for download vs show), that by default standards-compliant browsers will comply with (I'll allow for users over-riding this default behavior with configuration, if the browser wants to support that, sure).
It would be annoying too. If I want to open bunch of such links as background tabs then I would need to temporally change this setting and don't forget to return it.
From usability standpoint (ignoring security and performance considerations) it's better to show me content and save button simultaneously. Then why do it only when site author wants it? Saving images is common operation and it would be better to show save button for every non-dynamic content.
Why modern browsers don't have save button (https://upload.wikimedia.org/wikipedia/en/0/0f/Opera_3.62.pn... ) on toolbar by default and want users to use menus for such common operation? Because designers don't have a place to put it without reducing usability for most common scenarios of browser use. Also save button was not replacement for "Save as" in context menu.
Do we have solution for situation when application is complex enough that there is bunch of operations which are used rarely but must be easily accessible in one click and could be context-dependant?
I really would love if Dolphin Browser and Opera Mini would open PDF files in browser. Downloading files for viewing and opening PDF reader really isn't nice option, when you simply want to have a quick look what the file is really about.
Google's quick view has saved me many times. But there really should be one simple and good solution for this problem.
Mobile Chrome often gets this correct. For many file types it will ask what you want to do if you haven't set a default action. Just never set a default and it always asks.
Isn't that exactly what browsers ask you when you click in "Save as"? Ok, it's not "display in browser", it's just "display" (or "open"), but what's the difference?
Agreed. Depending on context (of the content and myself!), sometimes I'll want to save and sometimes not.
A prompt from the browser would be the best option, but alternatively, I'd want the site to offer me an option as to how the external file should be handled. If the browser doesn't implement it, it says that the "Right click to save" nonsense could make sense.
I moved to Chrome just to be able to see PDFs in browser. Lots of websites have info that way (restaurants are the worst) and I don't want to get it saved on my computer just to have to delete it!
The option approach with the ability to set a default is the best approach. Then depending on the default, the right click will show the non-default option.
> but the web app/page is forcing me to save it to disk and then re-open it in another app.
because SumatraPDF actually loads faster than Adobe's browser plugin. Plus it's more secure, lacking all the weird scripting crud that shouldn't be in a document format anyway, smaller and open source. Only downside is that it can be really, really, really yellow.
Yes, I do this all the time. I read a _lot_, and I often don't want to save the file on my hard drive unless I'm going to refer to it again in the future. And if I do, I can just choose "Save" at that point.
I set my default download location to /tmp, which on my OS is automatically cleaned up. If I want to keep something I move it to my home directory after looking at it. Otherwise, I can just forget about it.
As long as people (mostly academia and research orgs) continue to publish their content exclusively in PDF form, then there will be a need to look at that content in a web browser.
I work at a university and it is amazing at how much content exists only as a PDF, even if it would be better suited as regular old HTML content. Trying to turn that ship around would also interfere with numerous business processes and entrenched ways of doing things.
I've tried to get people to stop with the PDF madness, but the admin who follows a publish process written down on a set of ten-year-old Post-It notes simply just does not get it.
To be fair, there are a number of advantages to having content in PDF's rather than HTML. For example,
1. The formatting is more static. Papers and memos and other documents are created and intended to be artifacts, not just mutable information, and PDFs can preserve that better. In 10 years, the PDF will look more like it did originally than HTML in tomorrow's browsers.
2. They're more durable. As a self-contained document, they don't rely on externally served files such as JavaScript and CSS. Ideally most HTML files are capable of presenting their semantic content even when you strip all that away, but that's easy to get wrong (especially with the advent of client-side templating and JavaScript frameworks). It's easier to archive a PDF than a web page, just save it to a thumb drive and it's pretty much guaranteed to work.
3. It's every bit as future-proof as HTML. With multiple independent implementations of PDF viewers, many of which are open source, the format is not going away. It will be readable for years to come.
PDF preserves layout whereas html doesn't (generally, although it can preserve layout somewhat if you specify one font, fix font sizes, and fix all dimensions), but that's a negative for PDFs.
Different displays have different resolutions and different dimensions. That makes fixed layouts obnoxious to read on e-readers. The most obvious example of how fixed formatting is an abomination is a PDF on an ebook reader.
There is one reigning reason for having a fixed page layout: ability to cite pages, e.g. for academic citations.
There is no need to cite pages for works that have good digital versions, other than antiquated citation requirements (e.g. MLA/CMS). Ebook readers have text search. Cite a digital form of the work, and anyone with that work in digital form can find it... an exception being OCR'd pdfs and ebooks converted from PDFs, because OCR often screws up line breaks or has other errors that make searching unreliable.
For less-granular searching, there's section, table, and image numbering/labeling. Again, fixed layout is not required to make content searchable.
I think you're missing a key part of citing (at least for me), paraphrasing. When discussing sentiment or similar without quoting, you wouldn't know what to search for. It makes sense to give a page number to review and get more information on the source, without that you wouldn't know where to look. You'd have to read the entire source.
For text, only section in your "less-granular searching" would work, and not necessarily particularly well. Page number would often be more granular, and that's what's needed for paraphrasing - exactly where to find what you're discussing - but not exactly what it said.
If you're paraphrasing, then you could direct-quote a critical part of the text so that a reader knows what to search for.
A writer could also adopt page-neutral paragraph or sub-paragraph numbering. This is common, for instance, in classical texts (where such numbering has been done retrospectively, by scholars, because of the difficulties of citing passages with so many translations - the same general problem that paraphrasing has). To cite a few major examples, Plato's and Artistotle's works have such numbering, as does Hobbes' Leviathan.
Page numbering has poor granularity for citations in real scholarly work (where you'd ideally want to be able to cite within a few lines at most), and it prohibits flowed text. If someone has some case where they think they need page numbers for citations, they should figure out an alternative (a few of which have been outlined above).
No, I totally agree with you on all those points –– and they definitely highlight the value of PDF as a format.
My quarrel is with misapplications of PDF as a way of presenting regular old page content that would probably never get printed, stuff such as lists of contacts, FAQs, blog posts, etc.
I work with folks across a university who know how to make a PDF and embed a hyperlink into a page...and that's all they can do. Their content might be better off as a regular page, but it's a PDF because that's how they learned to upload content to a website in the absence of a CMS. I know, it's weird, but that's what I see on a day-to-day basis.
>> when I want to look at a PDF in browser
> does that ever happen?
Yeah, I've done it a few times. It's handy when I know I'm not going to save the PDF for any length of time. Using Foxit Reader helps with this since it's a lot lighter than anything from Adobe.
>> when I want to look at a PDF in browser
> does that ever happen?
I do this all the time. I hate downloading crap that I'm probably just going to glance at once then discard.
OK yes I understand better now. I never realized that other browsers apparently don't offer the "open with default application" option in the download dialog, like Opera does.
And actually quite some other applications do this (open as a temporary file) as well, it's a very common pattern: 7-Zip, FileZilla, to name a few.
And even if you didn't, there's always a temp directory that gets cleaned next reboot. Though I agree, the browser should take care of this, like most apps.
Default application, yes. A browser tab, no. When I just want to look at an image, firefox is largely preferable to gimp. When I have a bunch of pdfs, firefox tabs are easier to manage than evince windows.
But anyways, when pages use this already, it OFTEN pisses me off, when I want to look at a PDF in browser, but the web app/page is forcing me to save it to disk and then re-open it in another app.
What we _really_ need, that we _don't_ have a way to do right now -- is signal the browser to _prompt_ the user as to whether it should be saved or displayed in-browser. The browser could ignore unless it was capable of displaying in-browser of course. That's something we do not have any way of doing in a reliable way now with HTTP headers, and I wish html5 would add that, instead of duplicating a lesser feature which is both possible now, and frequently annoying.