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

Fri Feb 8 12:15:35 UTC 2013

The HttpResponse implementation in Mono is located here:
https://github.com/mono/mono/blob/master/mcs/class/System.Web/System.Web/HttpResponse.cs

I noticed this piece of code:

if (worker_request != null)
	use_chunked = (worker_request.GetHttpVersion () == "HTTP/1.1");

Which HttpResponseStream<https://github.com/mono/mono/blob/master/mcs/class/System.Web/System.Web/HttpResponseStream.cs>uses
to determine whether to chunk the response. Maybe you could try
hard-coding that variable to false and see if that fixes your problem?

If so, the fix is probably to disable response chunking when FastCGI is
being used (not just when the protocol is not HTTP/1.1).

On Fri, Feb 8, 2013 at 2:31 AM, SirNoSkill <quandary82 at hailmail.net> wrote:

> **
> Hi,
>
>
> I've forwarded the error to the nginx mailing list.
>
>
> http://forum.nginx.org/read.php?2,235985,235988#msg-235988
>
> The response I got:
> It's bad idea to use "Transfer-Encoding" while working via CGI and
> derived protocols like FastCGI. Quote from RFC 3875,
> http://tools.ietf.org/html/rfc3875#section-6.3.4:
>
> The script MUST NOT return any header fields that relate to
> client-side communication issues and could affect the server's
> ability to send the response to the client.
>
> As you are talking to nginx via FastCGI, not HTTP, it won't try to
> dig into content returned and decode it according to any
> Transfer-Encoding. Instead, the "Transfer-Encoding" header
> returned will be just dropped by nginx as per RFC 3875.
>
>
>
>
>
>
> On Sat, Feb 2, 2013, at 09:00 PM, SirNoSkill 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...
>
>
> --
>  SirNoSkill
>  quandary82 at hailmail.net
>
> -- http://www.fastmail.fm - IMAP accessible web-mail
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130208/24317403/attachment.html>