I recently needed to implement an HttpHandler in a project to handle retrieval of rendered PDF reports from a database. It shouldn't have been a big deal, very few lines of code, even less than typical since my Business Logic Layer encapsulates all of the aspects of the data retrieval itself into a single line of code... my handler only had to set the ContentType, add a couple of headers (Content-Length and Content-Disposition), and then BinaryWrite() the data. Easy as pie, or so I thought.
The file streamed fine out of the database - no surprises there. Content-Length had no issue and once I remembered to install Acrobat Reader into my VPC where I was testing this, then the ContentType of "application/pdf" worked as well.
But try as I might, I could not seem to get that darn Content-Disposition to be recognized by Internet Explorer! Every time I tested it, the "Save" dialog would always display a random file name, instead of the one I supplied in the header.
I double-checked, then triple-checked my code. I had two other web developers look at the code, and give it a thumbs-up. I even resorted to tracing the HTTP protocol traffic just to be 100% certain that IE was getting the HTTP header. Sure enough, the header was being set and IE was seeing it. But it wasnt obeying it.
It turns out there seems to be a maximum length to the filename you can supply using the attachment notation of the Content-Disposition header. And my filename was in excess of that limit, causing it to be ignored by IE. While I am not sure what the exact limit is (or if it is some other kind of esoteric bug in IE), and do not have time to experiment and discover that limit, simply reducing the length of my attachment filename has resolved the issue.
By the way, the length of the filename causing a problem was only something like 40 to 50 characters, which really isn't unrealistic. I was embedding the report execution date/time (in a string format that is valid in a file name), in order to prevent saved reports from being overwritten.