The Curious Case of Chrome, Content-Disposition and the Comma.

Chrome just works. It’s generally cleaner, faster and it simply feels better than IE, FireFox and Safari. So when I heard a client tell me that something wasn’t working specifically in Chrome, I thought nah, that can’t be right!

Well, turns out the client was right. File downloading in Chrome was apparently not working! So what happened?

The Issue: 

The site I am working on has a Print to PDF feature that will convert certain content types within the site to a printer friendly HTML format using a special CSS. The results of this HTML are stuffed into a PDF using a 3rd party component, then the bits are shipped the  to the browser as a file attachment. This all occurs in a single runtime operation and is pretty standard stuff.

When the bytes are sent to the browser, to get the file to download automatically we’re setting the content disposition as such:

Content-Disposition: attachment; filename=[content title].pdf

The issue lies in the replacement of the file name. For sake of argument lets say the content type is a forum post, and we’re using the title of the post as the file name. Let’s also say the title of the forum post is “Foo, How it Compels You”.

The resulting content disposition header would be:

Content-Disposition: attachment; filename=Foo, How it Compels You.pdf

In Chrome, when the content hits the client side, literally nothing happens. Network traffic shows the request was made, and data comes back, however no download occurs. On closer inspection you may get this message:

Content-Disposition headers received

This is happening because Chrome implements a stricter version of the content disposition header. Chrome pukes on the comma and considers this a possible security risk. Not sure how a comma can compromise your security, but I’ve heard stranger things.

The Fix:

Knowing that it’s the comma causing the problem, the fix was obvious: replace the comma with a space. Done.

It’s also worth noting that as a precaution additional character parsing was implemented to replace invalid Windows file characters with spaces, then replace any double spaces with single spaces.  In hind sight this should have been in place from the start. But that’s hind sight for you.



4 thoughts on “The Curious Case of Chrome, Content-Disposition and the Comma.

  1. Rogier Bom says:

    Hey Jim,

    It’s actualy not the comma that’s causing the issue. The filename should be enclosed in double quotes.

    This should work:

    Content-Disposition: attachment; filename=”Foo, How it Compels You.pdf”

    Kind regards,


    • jbarntish says:

      Hi Rogier,

      If memory serves, at the time we were dealing with a client that was pinned to an older version of Chrome (v16 to be exact), which I may have neglected to mention in this post. I do specifically remember adding quotes to the file name, with no success.

      I think the latest version of Chrome has since fixed this bug, though I haven’t gone back and verified.


  2. Liam says:

    Thanks very much for this! I had a similar issue: Content-Disposition was forcing a PDF to download in Safari but in Chrome PDFs were still opening in Chrome’s internal PDF viewer (interesting discussion in Chromium Issue 142947).

    I wasn’t setting/sending the filename-parm parameter (probably not the best) but was setting (disposition-type) “attachment”. When a filename had capital letters, Chrome displayed the file in-browser. Change the case of the filename to all lowercase and Chrome downloaded the file, like Safari.

    Interesting that Chrome strictly considers letter case as well.

  3. Chris Wilson says:

    It’s not a security risk but it is invalid HTTP, because a comma has a special meaning in HTTP headers: it’s used to separate multiple value of the same header. So the header that you posted is exactly equivalent to:

    Content-Disposition: attachment; filename=Foo
    Content-Disposition: How it Compels You.pdf

    Which Chrome is understandably not happy with: this header is not supposed to have multiple values anyway, and the second is not a valid disposition. Other browsers must be papering over the cracks of this invalid value.

    I think the correct solution is to quite the filename, and I’m surprised that it apparently doesn’t work in some cases.

The power compels you ...

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: