[Mono-dev] Bug in mono 3.0.1 MVC3 File/FileResult
Daniel Lo Nigro
lists at dan.cx
Sun Feb 3 10:45:03 UTC 2013
That does look like a bug with how Mono handles TransmitFile - I suggest
reporting it as a bug in Xamarin Bugzilla (report it under the System.Web
component).
Also FYI it's probably best if you pull down those pages for now; you're
not validating the "myfile" parameter so it's open to a Remote File
Inclusion <http://en.wikipedia.org/wiki/Remote_file_inclusion>vulnerability.
On Sun, Feb 3, 2013 at 9:38 PM, quandary <quandary82 at hailmail.net> wrote:
> Yep, indeed that sounds like that.
> And I just tested.
> Added WriteFile.ashx and Transmit.ashx
>
> and testet with
> http://www.daniel-steiger.ch/WriteFile.ashx
> http://www.daniel-steiger.ch/Transmit.ashx
> and
> http://www.daniel-steiger.ch/WriteFile.ashx?myfile=avatar100.png
> http://www.daniel-steiger.ch/Transmit.ashx?myfile=avatar100.png
>
>
> It seems the bug is in Response.TransmitFile for files of any size
> (also for avatar100.png, which is only 4.3 kb)
>
> so to summarize, there is a rather bad-natured bug in
> Class: System.Web.HttpResponse
> Method: TransmitFile(string filename)
>
>
> This is the transmit-handler code:
>
> using System;
> using System.Collections.Generic;
> using System.Linq;
> using System.Web;
>
> namespace Homepage
> {
> /// <summary>
> /// Zusammenfassungsbeschreibung für Transmit
> /// </summary>
> public class Transmit : IHttpHandler
> {
>
> public void ProcessRequest(HttpContext context)
> {
> string strFile = context.Request.Params["myfile"];
>
> if (string.IsNullOrEmpty(strFile))
> strFile = "001.jpg";
>
> string strNetPath =
> string.Format("~/Content/images/gallery/{0}", strFile);
> string strFileNameAndPath =
> context.Server.MapPath(strNetPath);
>
> context.Response.Clear();
> context.Response.ContentType = "image/jpeg";
> context.Response.TransmitFile(strFileNameAndPath);
> }
>
> public bool IsReusable
> {
> get
> {
> return false;
> }
> }
> }
>
> }
>
>
>
> Regards
>
> Stefan
>
>
>
>
>
> On 02/03/2013 06:14 AM, Daniel Lo Nigro wrote:
>
> That sounds like chunked encoding, Wikipedia says (
> http://en.wikipedia.org/wiki/Chunked_transfer_encoding):
> *Each chunk starts with the number of octets of the data it embeds
> expressed in hexadecimal followed by optional parameters (chunk
> extension) and a terminating CRLF sequence, followed by the chunk data.
> The chunk is terminated by CRLF. If chunk extensions are provided, the
> chunk size is terminated by a semicolon followed with the extension name
> and an optional equal sign and value.*
>
> Which is exactly what you're saying. I wonder if something is not being
> done correctly with files as large as the ones you're using. Since you said
> it works for thumbnails, I assume it's working for smaller files.
>
> Try Response.WriteFile or Response.TransmitFile in a standard ASP.NEThandler (.ashx) and see if they also don't work.
>
> 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.
>
> I'd still suggest letting Nginx serve your static files. Just because the
> site is low-traffic doesn't mean that little performance tweaks aren't good
> :). I do something like this:
> location / {
> # Pass requests for unknown files to Mono
> try_files $uri @mono;
> }
>
> location @mono {
> # Put all your Mono config here
> }
> My full site config is at
> https://github.com/Daniel15/Website/blob/master/nginx.conf
>
>
>
> On Sun, Feb 3, 2013 at 4:00 PM, SirNoSkill <quandary82 at hailmail.net>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...
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130203/73e31a9e/attachment-0001.html>
More information about the Mono-devel-list
mailing list