[Mono-dev] Bug in mono 3.0.1 MVC3 File/FileResult

SirNoSkill quandary82 at hailmail.net
Sun Feb 3 05:00:08 UTC 2013

I have more details on the bug.

The extra bytes that are at the beginning

31 39 36 62 36 38 0D 0A

which reads 196b68/r/n in ASCII

196b68 is the filesize of the original image in hex...

All details + hexdump links added here:


All traffic to that URL [[2]www.daniel-steiger.ch] (except for the
folders /doc and /images), but including images in /Content, is
directly forwarded to fastcgi by nginx, as per fastcgi config file for

 server {

         listen   80;

         server_name [3]www.daniel-steiger.ch daniel-steiger.ch;

         access_log   /var/log/nginx/daniel-steiger.ch.access.log;

         location / {

                 root /home/danillo/www/HomePage;

                 #index index.html index.htm default.aspx Default.aspx;

                 #fastcgi_index Default.aspx;


                 include /etc/nginx/fastcgi_params;


location /doc {

root /usr/share;

autoindex on;


deny all;


location /images {

root /usr/share;

autoindex off;


#error_page 404 /404.html;

# redirect server error pages to the static page /50x.html


error_page 500 501 503 504 /50x.html;

location = /50x.html {

root /home/danillo/www/HomePage;


error_page 502 /502.html;

location = /502.html {

root /home/danillo/www/HomePage;



It's sufficient to have the file served without FileResult.

Of course it's more efficient if nginx serves it directly, but this is
a very low traffic website, so performance is really not my problem ;)

And by the way, the problem is not finding a workaround.

I have already fixed it with a workaround about a week ago.

I really just want to know where the bug is, because if FileResult
malfunctions, there's probably more to it, and I don't want to walk
into a subtle not at the first sight spottable bug later, like a
botched binary upload/download file.

On Sat, Feb 2, 2013, at 06:51 AM, Daniel Lo Nigro wrote:

Hmm... Maybe try an X-Accel-Redirect header instead. This lets Nginx
serve the file instead of Mono having to serve it, which makes it more
efficient. See if that makes a difference, or if it has the same issue.

Why not just link directly to the file, instead of serving it through
your C# code?

On Sun, Feb 3, 2013 at 1:43 AM, quandary82 <[4]quandary82 at hailmail.net>

Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.

More here:



View this message in context:

Sent from the Mono - Dev mailing list archive at Nabble.com.

Mono-devel-list mailing list
[7]Mono-devel-list at lists.ximian.com



quandary82 at hailmail.net


1. http://stackoverflow.com/questions/14662795/why-do-i-have-unwanted-extra-bytes-at-the-beginning-of-image
2. http://www.daniel-steiger.ch/
3. http://www.daniel-steiger.ch/
4. mailto:quandary82 at hailmail.net
5. http://stackoverflow.com/questions/14662795/why-do-i-have-unwanted-extra-bytes-at-the-beginning-of-image
6. http://mono.1490590.n4.nabble.com/Bug-in-mono-3-0-1-MVC3-File-FileResult-tp4658382p4658422.html
7. mailto:Mono-devel-list at lists.ximian.com
8. http://lists.ximian.com/mailman/listinfo/mono-devel-list

http://www.fastmail.fm - mmm... Fastmail...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130202/a3278bf1/attachment-0001.html>

More information about the Mono-devel-list mailing list