I got assigned a rather annoying bug today whereby when a user using Firefox 7 went to a page that streamed a file for download, Firefox immediately stopped processing the page and returned the following error

Corrupted Content Error

A little bit of GoogleFu brought me to Firefox Bug #681140 - Corrupted Content error due to multiple Content-Disposition header field instances, new in Firefox 7.

There are a couple of reasons why this error will get thrown but the bottom line is Firefox thinks this is a form of response-smuggling and blocks it, in fact it doesn’t just block it, it denies any knowledge of anything to do with it, I could not for the life of me get Firefox to give me the response headers no matter what extension I used. In the end fiddler revealed the issue

content-disposition: attachment
Content-Disposition: attachment; filename="results.xls"

Fairly simple issue here, there are two Content-Disposition headers being sent to the browser and Firefox 7 throws it’s toys out of the pram if there is more than one.

Now, the cause.

I loaded up the controller that was generating these downloads and right enough, I found

Response.AddHeader("content-disposition", "attachment");
return File(content, format, filename);

I think you can see where I am going here. MVC is pretty good at removing a lot of the boiler plate we normally have to write and this is one of those cases. When you use the Controller.File method a number of headers are automatically set for you on the Response stream, if you provide a file name then one of those headers is Content-Disposition.

Ta-da, the source of the duplication.

So, when using FileResult in MVC, be very careful which additional headers you send out, check them in something like fiddler and don’t just assume that browsers in the future will accept malformed or duplicate headers.

Posted in MVC.

Update: Jarek has pointed out that the solution presented won’t be necessary in the final version which is good news.

Update: (18/04/11): This is no longer required as of the latest NLog 2.0 nightly build, see http://nlog-project.org/2011/04/14/simplifying-nlog-extended-dll-usage.html for more details!

I recently upgraded a web application to use NLog 2.0 beta 1 (from 1.0 refresh) and part of my layout makes use of ${aspnet-request} in order to get things like IP and request URL. After upgrading, the application refused to start and would throw the following exception.

LayoutRenderer cannot be found: ‘aspnet-request’
at NLog.Config.Factory`2.CreateInstance(String name) in c:\NLogBuild\src\NLog\Config\Factory.cs:line 170
at NLog.Layouts.LayoutParser.ParseLayoutRenderer(ConfigurationItemFactory configurationItemFactory, Tokenizer sr) in c:\NLogBuild\src\NLog\Layouts\LayoutParser.cs:line 210
at NLog.Layouts.LayoutParser.CompileLayout(ConfigurationItemFactory configurationItemFactory, Tokenizer sr, Boolean isNested, String& text) in c:\NLogBuild\src\NLog\Layouts\LayoutParser.cs:line 78
at NLog.Layouts.SimpleLayout.set_Text(String value) in c:\NLogBuild\src\NLog\Layouts\SimpleLayout.cs:line 113

Now one of the changes in NLog 2.0 is that a number of layout renderers have been moved to NLog.Extended.dll, and I had made sure that my application referenced the new DLL as well as NLog.dll. When I ran the application I could confirm that both DLLs were present and loaded any yet my application still crashed out.

I posted this problem on the NLog Forums and while someone else is having the same problem, I never got a solid answer from the post. Today, 2 weeks later, I was perusing the forums just in case there were others reporting this problem and I came across a post where someone was describing similar issues, amongst the replies was a solution from Jarek Kowalski, the creator of NLog. Jarek points out that to use the layout renderers in NLog.Extended you need to add a few lines to your NLog config.

<nlog>
  <extensions>
    <add assembly="NLog.Extended" />
  </extensions>
  ...
</nlog>

You also need to make sure that NLog.Extended.dll is in the same folder as NLog.dll.

Once I saw this it made perfect sense but I never saw this anywhere in the documentation relating to changes in NLog 2.0. I added the snippet to my application’s config file and I was once again able to use ${aspnet-request}.

Happy logging