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

[SirNoSkill]

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:

[1]http://stackoverflow.com/questions/14662795/why-do-i-have-unwanted-e
xtra-bytes-at-the-beginning-of-image







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
domain.





 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;

                 fastcgi_pass 127.0.0.1:9000;

                 include /etc/nginx/fastcgi_params;

         }





location /doc {

root /usr/share;

autoindex on;

allow 127.0.0.1;

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>
wrote:

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



More here:

[5]http://stackoverflow.com/questions/14662795/why-do-i-have-unwanted-e
xtra-bytes-at-the-beginning-of-image







--

View this message in context:
[6]http://mono.1490590.n4.nabble.com/Bug-in-mono-3-0-1-MVC3-File-FileRe
sult-tp4658382p4658422.html

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

_______________________________________________
Mono-devel-list mailing list
[7]Mono-devel-list at lists.ximian.com
[8]http://lists.ximian.com/mailman/listinfo/mono-devel-list



--

SirNoSkill

quandary82 at hailmail.net

References

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>