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

SirNoSkill quandary82 at hailmail.net
Fri Feb 8 14:01:48 UTC 2013


I agree, looks like the right place for the fix.

Quizz question is, how to find out if fastcgi is being used or not, but
I suppose uncertainty about that is what the hard-coding is for :)

If I have sufficient time, I will recompile mono with that change this
evening and try.

When I recompile mono, should I use 3.0.3 stable, or the latest git
master trunk (stable enough today?) ?

Anybody else has something that needs quick testing, while I am at it ?





Also I noticed I get this error here that somebody else posted

[1]http://stackoverflow.com/questions/10160605/mono-random-cs0006-compi
lation-errors-w-fastcgi-mono-server4

from time to time.



I have some further information on it:

- happens when I update the ASP.NET MVC3 application and don't restart
the fastcgi-server (it should probably restart the application from
scratch in that case, especially as the web.config is being replaced).

- Sometimes (not that often) also just happens when the
application runs for a long time (maybe app-pool recycling?).

- Happens to me only in the gallery controller, rest works fine (very
mean, you have to click through everything to notice it)

- when I run aot on ./*.dll in the /bin folder, as advised in the post,
it fails complaining about a reference to a 2.0 System.Web.dll
somewhere in a dependency reference (project is 4.0, but I didn't have
the time to look at it closer in the last 10 minutes of my lunchtime
break)











On Fri, Feb 8, 2013, at 04:15 AM, Daniel Lo Nigro wrote:

The HttpResponse implementation in Mono is located
here: [2]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 [3]HttpResponseStream 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 <[4]quandary82 at hailmail.net>
wrote:

Hi,

I've forwarded the error to the nginx mailing list.

[5]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,
[6]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:

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







All traffic to that URL [[8]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 [9]www.daniel-steiger.chdaniel-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 [10]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
<[11]quandary82 at hailmail.net> wrote:

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



More here:

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







--

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

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

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



--

SirNoSkill

[16]quandary82 at hailmail.net

--
[17]http://www.fastmail.fm - mmm... Fastmail...


--
SirNoSkill
[18]quandary82 at hailmail.net
--
[19]http://www.fastmail.fm - IMAP accessible web-mail



--

SirNoSkill

quandary82 at hailmail.net

References

1. http://stackoverflow.com/questions/10160605/mono-random-cs0006-compilation-errors-w-fastcgi-mono-server4
2. https://github.com/mono/mono/blob/master/mcs/class/System.Web/System.Web/HttpResponse.cs
3. https://github.com/mono/mono/blob/master/mcs/class/System.Web/System.Web/HttpResponseStream.cs
4. mailto:quandary82 at hailmail.net
5. http://forum.nginx.org/read.php?2,235985,235988#msg-235988
6. http://tools.ietf.org/html/rfc3875#section-6.3.4
7. http://stackoverflow.com/questions/14662795/why-do-i-have-unwanted-extra-bytes-at-the-beginning-of-image
8. http://www.daniel-steiger.ch/
9. http://www.daniel-steiger.ch/
  10. http://127.0.0.1:9000/
  11. mailto:quandary82 at hailmail.net
  12. http://stackoverflow.com/questions/14662795/why-do-i-have-unwanted-extra-bytes-at-the-beginning-of-image
  13. http://mono.1490590.n4.nabble.com/Bug-in-mono-3-0-1-MVC3-File-FileResult-tp4658382p4658422.html
  14. mailto:Mono-devel-list at lists.ximian.com
  15. http://lists.ximian.com/mailman/listinfo/mono-devel-list
  16. mailto:quandary82 at hailmail.net
  17. http://www.fastmail.fm/
  18. mailto:quandary82 at hailmail.net
  19. http://www.fastmail.fm/

-- 
http://www.fastmail.fm - One of many happy users:
  http://www.fastmail.fm/help/overview_quotes.html

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


More information about the Mono-devel-list mailing list