[Mono-dev] Bug in mono 3.0.1 MVC3 File/FileResult
quandary
quandary82 at hailmail.net
Tue Feb 12 05:13:48 UTC 2013
added patch
On 02/11/2013 11:21 PM, Andres G. Aragoneses wrote:
>
> 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
>>
>
>
> _______________________________________________
> 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