[Mono-dev] Bug in mono 3.0.1 MVC3 File/FileResult
quandary
quandary82 at hailmail.net
Mon Feb 11 20:12:43 UTC 2013
Horray, used mono 3.0.3 stable, and "use_chuncked = false;" fixed it.
Thanks ! ;)
nginx defines this fastcgi parameter:
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
So here a proper patch (tested - works, maybe add ordinalignorecase to
startswith ?):
/root/sources/mono/3.0.3/mono-3.0.3/mcs/class/System.Web/System.Web/HttpResponse.cs
starting at line 125:
internal HttpResponse (HttpWorkerRequest worker_request,
HttpContext context) : this ()
{
WorkerRequest = worker_request;
this.context = context;
#if !TARGET_J2EE
if (worker_request != null)
{
if(worker_request.GetHttpVersion () == "HTTP/1.1")
{
string GatewayIface =
context.Request.ServerVariables["GATEWAY_INTERFACE"];
use_chunked = (GatewayIface == null ||
!GatewayIface.StartsWith("CGI"));
}
else
use_chunked = false;
}
#endif
writer = new HttpWriter (this);
}
Wonderful:
http://www.daniel-steiger.ch/TransmitFile.ashx
Thanks ! ;)
On 02/08/2013 01:15 PM, Daniel Lo Nigro wrote:
> 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
> <mailto: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
>> |3139366236380D0A|
>> ||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
>> <http://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
>> <http://www.daniel-steiger.ch> daniel-steiger.ch
>> <http://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 <http://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 <mailto: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
>>> <mailto:Mono-devel-list at lists.ximian.com>
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>> --
>> SirNoSkill
>> quandary82 at hailmail.net <mailto:quandary82 at hailmail.net>
>> --
>> http://www.fastmail.fm - mmm... Fastmail...
> --
> SirNoSkill
> quandary82 at hailmail.net <mailto: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/20130211/1b3a6f8c/attachment.html>
More information about the Mono-devel-list
mailing list