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

Sun Feb 3 05:14:43 UTC 2013

That sounds like chunked encoding, Wikipedia says (
http://en.wikipedia.org/wiki/Chunked_transfer_encoding):
*Each chunk starts with the number of octets of the data it embeds
expressed in hexadecimal followed by optional parameters (chunk extension)
and a terminating CRLF sequence, followed by the chunk data. The chunk is
terminated by CRLF. If chunk extensions are provided, the chunk size is
terminated by a semicolon followed with the extension name and an optional
equal sign and value.*

Which is exactly what you're saying. I wonder if something is not being
done correctly with files as large as the ones you're using. Since you said
it works for thumbnails, I assume it's working for smaller files.

Try Response.WriteFile or Response.TransmitFile in a standard
ASP.NEThandler (.ashx) and see if they also don't work.

All traffic to that URL [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.

I'd still suggest letting Nginx serve your static files. Just because the
site is low-traffic doesn't mean that little performance tweaks aren't good
:). I do something like this:
location / {
# Pass requests for unknown files to Mono
try_files $uri @mono;
}

location @mono {
# Put all your Mono config here
}
My full site config is at
https://github.com/Daniel15/Website/blob/master/nginx.conf

On Sun, Feb 3, 2013 at 4:00 PM, SirNoSkill <quandary82 at hailmail.net> wrote:

> **
> 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:
>
> http://stackoverflow.com/questions/14662795/why-do-i-have-unwanted-extra-bytes-at-the-beginning-of-image
>
>
>
> All traffic to that URL [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 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 <quandary82 at hailmail.net>wrote:
>
>> Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
>>
>>  More here:
>>
>> http://stackoverflow.com/questions/14662795/why-do-i-have-unwanted-extra-bytes-at-the-beginning-of-image
>>
>>
>>
>>  --
>>  View this message in context:
>> http://mono.1490590.n4.nabble.com/Bug-in-mono-3-0-1-MVC3-File-FileResult-tp4658382p4658422.html
>>  Sent from the Mono - Dev mailing list archive at Nabble.com.
>> _______________________________________________
>>  Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
> --
>  SirNoSkill
>  quandary82 at hailmail.net
>
> -- http://www.fastmail.fm - mmm... Fastmail...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130203/c38128af/attachment.html>