[Mono-dev] Bug in mono 3.0.1 MVC3 File/FileResult
Andres G. Aragoneses
knocte at gmail.com
Mon Feb 11 22:21:56 UTC 2013
Looks about right. Do you mind posting a patch in the bug or propose a
pull request?
On 11/02/13 20:12, quandary wrote:
> 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
>>
>>
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
More information about the Mono-devel-list
mailing list