Monthly Archives: October 2012

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.