Quantcast

Bug in mono 3.0.1 MVC3 File/FileResult

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug in mono 3.0.1 MVC3 File/FileResult

quandary82

There is a bug in mono 3.0.1.
I don't know if it is fixed in 3.0.3


If in a asp.net MVC3 controller, I call File via path (probably uses
FilePathResult)
like this
http://www.daniel-steiger.ch/gallery/FullImage/001.jpg?no_cache=1358694795000

I get the image data as text.
The path is correct.
The mime is correct.
The image itselfs is valid.

If I call the url to the image directly and not via the "File" method,
then it works
Proof:
http://www.daniel-steiger.ch/Content/images/gallery/002.jpg?LastWriteTimeUTC=1358694795000

Ironically, generating the thumbnail works (that probably goes via
FileStreamResult).
Both work correctly on windows.


PS:
The latest-stable install script for xsp misses copying
fastcgi-mono-server4, mod-mono and xsp  to the 4.5 gac.
Same things applies to Microsoft.VisualBasic.dll.
See here:
http://stackoverflow.com/questions/4239645/does-the-razor-view-engine-work-for-mono




namespace Homepage.Controllers
{


    public class GalleryController : Controller
    {


        protected static string GetImageDirectory()
        {
            string bd = AppDomain.CurrentDomain.BaseDirectory;
            string strImageDirectory = System.IO.Path.Combine(bd,
            "Content");
            strImageDirectory =
            System.IO.Path.Combine(strImageDirectory, "images");
            strImageDirectory =
            System.IO.Path.Combine(strImageDirectory, "gallery");

            return strImageDirectory;
        } // End Function GetImageDirectory


        protected static string strImageDirectory = GetImageDirectory();

   
        public FileResult FullImage(string id)
        {
            string strFileName =
            System.IO.Path.Combine(strImageDirectory, id);

            //return new FilePathResult("CorrectFullPathAndFileName",
            "CorrectMime");
            return File(strFileName, "image/jpg");
        } // End Action FullImage



        public FileResult Thumb(string id)
        {
            //return Redirect(id);

            string strFileName =
            System.IO.Path.Combine(strImageDirectory, id);

            System.IO.Stream ms =
            Tools.Imaging.GetThumbnailStream(strFileName,
            System.Drawing.Imaging.ImageFormat.Png);
            return File(ms, "image/png");
            /*
            using (System.IO.Stream ms =
            Tools.Imaging.GetThumbnailStream(strFileName,
            System.Drawing.Imaging.ImageFormat.Png))
            {
                return File(ms, "image/png");
            }*/
        } // End Action Thumb


    } // End Class GalleryController : Controller


} // End Namespace Homepage.Controllers



--
  SirNoSkill
  [hidden email]

--
http://www.fastmail.fm - Email service worth paying for. Try it for free

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

Daniel Lo Nigro
Not a bug in Mono, you're just sending the wrong mime-type (and the browser isn't recognising that it's an image). image/jpg should actually be image/jpeg.

I noticed you're using Nginx, I'd probably use a custom ActionResult that uses the X-Accel-Redirect header for better performance. This lets Nginx serve the file based on a HTTP header your code returns.


On Wed, Jan 30, 2013 at 2:59 AM, SirNoSkill <[hidden email]> wrote:

There is a bug in mono 3.0.1.
I don't know if it is fixed in 3.0.3


If in a asp.net MVC3 controller, I call File via path (probably uses
FilePathResult)
like this
http://www.daniel-steiger.ch/gallery/FullImage/001.jpg?no_cache=1358694795000

I get the image data as text.
The path is correct.
The mime is correct.
The image itselfs is valid.

If I call the url to the image directly and not via the "File" method,
then it works
Proof:
http://www.daniel-steiger.ch/Content/images/gallery/002.jpg?LastWriteTimeUTC=1358694795000

Ironically, generating the thumbnail works (that probably goes via
FileStreamResult).
Both work correctly on windows.


PS:
The latest-stable install script for xsp misses copying
fastcgi-mono-server4, mod-mono and xsp  to the 4.5 gac.
Same things applies to Microsoft.VisualBasic.dll.
See here:
http://stackoverflow.com/questions/4239645/does-the-razor-view-engine-work-for-mono




namespace Homepage.Controllers
{


    public class GalleryController : Controller
    {


        protected static string GetImageDirectory()
        {
            string bd = AppDomain.CurrentDomain.BaseDirectory;
            string strImageDirectory = System.IO.Path.Combine(bd,
            "Content");
            strImageDirectory =
            System.IO.Path.Combine(strImageDirectory, "images");
            strImageDirectory =
            System.IO.Path.Combine(strImageDirectory, "gallery");

            return strImageDirectory;
        } // End Function GetImageDirectory


        protected static string strImageDirectory = GetImageDirectory();


        public FileResult FullImage(string id)
        {
            string strFileName =
            System.IO.Path.Combine(strImageDirectory, id);

            //return new FilePathResult("CorrectFullPathAndFileName",
            "CorrectMime");
            return File(strFileName, "image/jpg");
        } // End Action FullImage



        public FileResult Thumb(string id)
        {
            //return Redirect(id);

            string strFileName =
            System.IO.Path.Combine(strImageDirectory, id);

            System.IO.Stream ms =
            Tools.Imaging.GetThumbnailStream(strFileName,
            System.Drawing.Imaging.ImageFormat.Png);
            return File(ms, "image/png");
            /*
            using (System.IO.Stream ms =
            Tools.Imaging.GetThumbnailStream(strFileName,
            System.Drawing.Imaging.ImageFormat.Png))
            {
                return File(ms, "image/png");
            }*/
        } // End Action Thumb


    } // End Class GalleryController : Controller


} // End Namespace Homepage.Controllers



--
  SirNoSkill
  [hidden email]

--
http://www.fastmail.fm - Email service worth paying for. Try it for free

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

quandary82
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

Daniel Lo Nigro
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 <[hidden email]> 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
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

quandary82
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:
 
 
 
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 <[hidden email]> wrote:
Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
 
More here:
 
 
 
--
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
 
--
SirNoSkill
-- 
http://www.fastmail.fm - mmm... Fastmail...

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

Daniel Lo Nigro
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.NET handler (.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
}



On Sun, Feb 3, 2013 at 4:00 PM, SirNoSkill <[hidden email]> 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:
 
 
 
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 <[hidden email]> wrote:
Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
 
More here:
 
 
 
--
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
 
--
SirNoSkill
-- 
http://www.fastmail.fm - mmm... Fastmail...


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

quandary82
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.NET handler (.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
}



On Sun, Feb 3, 2013 at 4:00 PM, SirNoSkill <[hidden email]> 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:
 
 
 
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 <[hidden email]> wrote:
Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
 
More here:
 
 
 
--
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
 
--
SirNoSkill
-- 
http://www.fastmail.fm - mmm... Fastmail...



_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

Daniel Lo Nigro
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 vulnerability.


On Sun, Feb 3, 2013 at 9:38 PM, quandary <[hidden email]> 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.NET handler (.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
}



On Sun, Feb 3, 2013 at 4:00 PM, SirNoSkill <[hidden email]> 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:
 
 
 
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 <[hidden email]> wrote:
Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
 
More here:
 
 
 
--
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
 
--
SirNoSkill
-- 
http://www.fastmail.fm - mmm... Fastmail...




_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

quandary82
Oh wonderful, it's called remote file inclusion.
I suspected that much, but I didn't bother to address it,
because I didn't publish the sources and internal config files - up until today.

So with you having mentioned it for all script kiddies to see - site taken down until validation is added.
Before that, I quickly checked - one can access files below the root directory of the web application.

Isn't this a mono-bug, too ?
Because I think I remember me having done this once on a test or production server, and it gave a wonderful YSOD on IIS.





On 02/03/2013 11:45 AM, Daniel Lo Nigro wrote:
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 vulnerability.


On Sun, Feb 3, 2013 at 9:38 PM, quandary <[hidden email]> 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.NET handler (.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
}



On Sun, Feb 3, 2013 at 4:00 PM, SirNoSkill <[hidden email]> 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:
 
 
 
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 <[hidden email]> wrote:
Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
 
More here:
 
 
 
--
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
 
--
SirNoSkill
-- 
http://www.fastmail.fm - mmm... Fastmail...





_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

Daniel Lo Nigro
Better I mention it than risking someone more malicious noticing it, since the link was already in a public mailing list. :)

Isn't this a mono-bug, too ?
As far as I'm aware, the .NET Framework only validates for HTML tags in parameters. It doesn't validate file paths since it doesn't even know the parameter will be used for a file path (things like "..\" could be valid GET parameters for your page). I don't think there's any built in mechanism to prevent directory traversal.



On Sun, Feb 3, 2013 at 10:34 PM, quandary <[hidden email]> wrote:
Oh wonderful, it's called remote file inclusion.
I suspected that much, but I didn't bother to address it,
because I didn't publish the sources and internal config files - up until today.

So with you having mentioned it for all script kiddies to see - site taken down until validation is added.
Before that, I quickly checked - one can access files below the root directory of the web application.

Isn't this a mono-bug, too ?
Because I think I remember me having done this once on a test or production server, and it gave a wonderful YSOD on IIS.






On 02/03/2013 11:45 AM, Daniel Lo Nigro wrote:
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 vulnerability.


On Sun, Feb 3, 2013 at 9:38 PM, quandary <[hidden email]> 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.NET handler (.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
}



On Sun, Feb 3, 2013 at 4:00 PM, SirNoSkill <[hidden email]> 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:
 
 
 
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 <[hidden email]> wrote:
Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
 
More here:
 
 
 
--
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
 
--
SirNoSkill
-- 
http://www.fastmail.fm - mmm... Fastmail...






_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

quandary82
Remote file inclusion fixed, ashx handlers removed, FullImage removed, website back up.

Filed but 10'001
https://bugzilla.xamarin.com/show_bug.cgi?id=10001



No, I don't mean parameter validation, and RFI can't work in MVC when you request from a browser on Windows, because
parameters are separated by / and windows translates backslash to forwardslash.
(at least not until one uses a catchall parameter), I checked.

If you'd use a browser on Linux, I don't know if it would change backslashes into slashes,
which would be a potentially dangerous thing for a windows server.
But I have a Linux server, so who cares about that.

It can only work for parameters passed via QueryString/HttpPost, such as in the two ashx handlers I added.
(or if a confidential file is in the same directory, but that would be really stupid).


What I mean is file path validation in
Response.TransmitFile
Response.WriteFile
Server.MapPath
System.IO.Path.GetFiles
etc.
To check whether the requested file is not below the root directory of the web application
(so that it would throw an AccessDeniedException on TransmitFile).

Or in other words,
if( !strFileName.StartsWith(AppDomain.CurrentDomain.BaseDirectory, StringComparer.OrdinalIgnoreCase)
     throw new AccessDeniedException("no access to files below application root directory");

of course, the above is not sufficient, because relative paths in absolute paths are possible and supported by .NET/Windows/Linux.

Because if that path validation isn't done, one can request (for example in my previous handler)
wget http://www.daniel-steiger.ch/WriteFile.ashx?myfile=../../../../../../../etc/passwd
which makes RFI interesting in the first place.
I checked an it worked, I got /etc/passwd back...
Now /etc/passwd wouldn't be that bad,
since it only contains MD5 hashes (though MD5 is rainbow-table vulnerable) and because I configured ssh to not allow password logins,
but WriteFile.ashx?myfile=../../../../../../../root/.ssh/id_rsa would be really really bad.

I think I remember stumbling over such an exception somehow in IIS (perhaps SecurityException and not AccessDenied),
but not on the ASP.NET development server.





On 02/03/2013 12:41 PM, Daniel Lo Nigro wrote:
Better I mention it than risking someone more malicious noticing it, since the link was already in a public mailing list. :)

Isn't this a mono-bug, too ?
As far as I'm aware, the .NET Framework only validates for HTML tags in parameters. It doesn't validate file paths since it doesn't even know the parameter will be used for a file path (things like "..\" could be valid GET parameters for your page). I don't think there's any built in mechanism to prevent directory traversal.



On Sun, Feb 3, 2013 at 10:34 PM, quandary <[hidden email]> wrote:
Oh wonderful, it's called remote file inclusion.
I suspected that much, but I didn't bother to address it,
because I didn't publish the sources and internal config files - up until today.

So with you having mentioned it for all script kiddies to see - site taken down until validation is added.
Before that, I quickly checked - one can access files below the root directory of the web application.

Isn't this a mono-bug, too ?
Because I think I remember me having done this once on a test or production server, and it gave a wonderful YSOD on IIS.






On 02/03/2013 11:45 AM, Daniel Lo Nigro wrote:
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 vulnerability.


On Sun, Feb 3, 2013 at 9:38 PM, quandary <[hidden email]> 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.NET handler (.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
}



On Sun, Feb 3, 2013 at 4:00 PM, SirNoSkill <[hidden email]> 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:
 
 
 
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 <[hidden email]> wrote:
Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
 
More here:
 
 
 
--
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
 
--
SirNoSkill
-- 
http://www.fastmail.fm - mmm... Fastmail...







_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

Daniel Lo Nigro
RFI can't work in MVC 
Yeah, routing rules should block it, I forgot to mention that. I don't think ASP.NET MVC allows "\" in its route parameters.

But if you have the default route (/ControllerName/ActionName) enabled, your app could still be vulnerable. A user could pass the parameter as a GET or POST parameter (ie. go to /Gallery/FullImage?id=../../../../../../../etc/passwd) and the default model binder will accept this parameter. It's usually safer to always do validation of your parameters instead of relying on the routing engine to do it :)

What I mean is file path validation in 
Response.TransmitFile 
Response.WriteFile 
Server.MapPath 
System.IO.Path.GetFiles 
etc.
To check whether the requested file is not below the root directory of the web application 
But in some cases you might want to read files below the root directory (eg. some apps use c:\Windows\Temp or /tmp)

WriteFile.ashx?myfile=../../../../../../../root/.ssh/id_rsa would be really really bad.
This should never work as id_rsa should have its mode set to 0700 and Mono shouldn't be running as root. The user Mono runs as should be relatively locked down. I use www-data (the default web server / PHP-FPM user in Debian) for mine.


On Mon, Feb 4, 2013 at 12:03 AM, quandary <[hidden email]> wrote:
Remote file inclusion fixed, ashx handlers removed, FullImage removed, website back up.

Filed but 10'001
https://bugzilla.xamarin.com/show_bug.cgi?id=10001



No, I don't mean parameter validation, and RFI can't work in MVC when you request from a browser on Windows, because
parameters are separated by / and windows translates backslash to forwardslash.
(at least not until one uses a catchall parameter), I checked.

If you'd use a browser on Linux, I don't know if it would change backslashes into slashes,
which would be a potentially dangerous thing for a windows server.
But I have a Linux server, so who cares about that.

It can only work for parameters passed via QueryString/HttpPost, such as in the two ashx handlers I added.
(or if a confidential file is in the same directory, but that would be really stupid).


What I mean is file path validation in
Response.TransmitFile
Response.WriteFile
Server.MapPath
System.IO.Path.GetFiles
etc.
To check whether the requested file is not below the root directory of the web application
(so that it would throw an AccessDeniedException on TransmitFile).

Or in other words,
if( !strFileName.StartsWith(AppDomain.CurrentDomain.BaseDirectory, StringComparer.OrdinalIgnoreCase)
     throw new AccessDeniedException("no access to files below application root directory");

of course, the above is not sufficient, because relative paths in absolute paths are possible and supported by .NET/Windows/Linux.

Because if that path validation isn't done, one can request (for example in my previous handler)
wget http://www.daniel-steiger.ch/WriteFile.ashx?myfile=../../../../../../../etc/passwd
which makes RFI interesting in the first place.
I checked an it worked, I got /etc/passwd back...
Now /etc/passwd wouldn't be that bad,
since it only contains MD5 hashes (though MD5 is rainbow-table vulnerable) and because I configured ssh to not allow password logins,
but WriteFile.ashx?myfile=../../../../../../../root/.ssh/id_rsa would be really really bad.

I think I remember stumbling over such an exception somehow in IIS (perhaps SecurityException and not AccessDenied),
but not on the ASP.NET development server.






On 02/03/2013 12:41 PM, Daniel Lo Nigro wrote:
Better I mention it than risking someone more malicious noticing it, since the link was already in a public mailing list. :)

Isn't this a mono-bug, too ?
As far as I'm aware, the .NET Framework only validates for HTML tags in parameters. It doesn't validate file paths since it doesn't even know the parameter will be used for a file path (things like "..\" could be valid GET parameters for your page). I don't think there's any built in mechanism to prevent directory traversal.



On Sun, Feb 3, 2013 at 10:34 PM, quandary <[hidden email]> wrote:
Oh wonderful, it's called remote file inclusion.
I suspected that much, but I didn't bother to address it,
because I didn't publish the sources and internal config files - up until today.

So with you having mentioned it for all script kiddies to see - site taken down until validation is added.
Before that, I quickly checked - one can access files below the root directory of the web application.

Isn't this a mono-bug, too ?
Because I think I remember me having done this once on a test or production server, and it gave a wonderful YSOD on IIS.






On 02/03/2013 11:45 AM, Daniel Lo Nigro wrote:
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 vulnerability.


On Sun, Feb 3, 2013 at 9:38 PM, quandary <[hidden email]> 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.NET handler (.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
}



On Sun, Feb 3, 2013 at 4:00 PM, SirNoSkill <[hidden email]> 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:
 
 
 
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 <[hidden email]> wrote:
Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
 
More here:
 
 
 
--
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
 
--
SirNoSkill
-- 
http://www.fastmail.fm - mmm... Fastmail...








_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

quandary82
Granted, letting it run as root isn't a good idea, to say the least.
But I had too few time to deal with permission issues.
So in order to deal with the problem, I added some extension methods (see below) and will just use these in the future.
My TransmitFile.ashx handler should be back in safely with that, calling SafeTransmitFile instead.
 
PS:
I figured the problem might be a missing nginx configuration parameter, in which case it would be a documentation bug.
So I googled a bit, and tried a bit.

 
Based on the quora links, I added chunked_transfer encoding, proxy_http_version and fastcgi_keep_conn to the virtual name based hosting configuration of nginx.

 
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;
chunked_transfer_encoding on;
proxy_http_version 1.1;
#fastcgi_keep_conn on;
}
 
to the nginx virtual name based hosting config for that domain.

 
That doesn't make a difference (i restarted both nginx and fastcgi after the config change).
Also, switching proxy_http_version to 1.0 and chuncked_transfer_encoding to off doesn't make a difference.

 
But it should.
As the fastcgi-interface is set to 1.0, it shouldn't return a chunked_transfer_encoding at all, since this is part of http 1.1.
Unless I misplaced this config setting by putting it into location.


 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;


 

namespace System
{


 

    public static class SafetyExtensions
    {

        private static string m_strTempPath = System.IO.Path.GetTempPath();


 

        public static void SanityCheck(string strUntrustedFileNameAndPath)
        {
            if (string.IsNullOrWhiteSpace(strUntrustedFileNameAndPath))
                throw new ArgumentNullException("strUntrustedFileNameAndPath");
            string strAbsoluteFileNameAndPath = System.IO.Path.GetFullPath(strUntrustedFileNameAndPath);
            string strFileName = System.IO.Path.GetFileName(strAbsoluteFileNameAndPath);

            if (string.IsNullOrWhiteSpace(strAbsoluteFileNameAndPath))

                throw new NullReferenceException("strFileNameAndPath");

            if (string.IsNullOrWhiteSpace(strFileName))

                throw new NullReferenceException("strFileName");

            if (!strAbsoluteFileNameAndPath.StartsWith(AppDomain.CurrentDomain.BaseDirectory, StringComparison.OrdinalIgnoreCase))

            {
                if (!strAbsoluteFileNameAndPath.StartsWith(m_strTempPath, StringComparison.OrdinalIgnoreCase))
                    throw new UnauthorizedAccessException("Error: Path \"" + strAbsoluteFileNameAndPath + "\" is below the application root directory.");
            }


 

            if (strAbsoluteFileNameAndPath.StartsWith(System.IO.Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "App_Data"), StringComparison.OrdinalIgnoreCase))
                throw new UnauthorizedAccessException("Error: App_Data is a confidential directory.");

            if (StringComparer.OrdinalIgnoreCase.Equals(strFileName, "web.config"))

                throw new UnauthorizedAccessException("Error: Access for any file called \"web.config\" is denied.");

            if (StringComparer.OrdinalIgnoreCase.Equals(strFileName, "connections.config"))

                throw new UnauthorizedAccessException("Error: Access for any file called \"connections.config\" is denied.");

            if (StringComparer.OrdinalIgnoreCase.Equals(strFileName, "elmah.config"))

                throw new UnauthorizedAccessException("Error: Access for any file called \"elmah.config\" is denied.");

        } // End Sub SanityCheck


 

        public static string SafeMapPath(this HttpServerUtility srv, string path)
        {
            string strRet = srv.MapPath(path);
            SanityCheck(strRet);

            return strRet;

        }


 

        public static void SafeTransmitFile(this HttpResponse resp, string filename)
        {
            SanityCheck(filename);
            resp.TransmitFile(filename);
        }


 

        public static void SafeWriteFile(this HttpResponse resp, string filename)
        {
            SanityCheck(filename);
            resp.WriteFile(filename);
        }

    }

}

 
 
On Sun, Feb 3, 2013, at 01:57 PM, Daniel Lo Nigro wrote:
RFI can't work in MVC 
Yeah, routing rules should block it, I forgot to mention that. I don't think ASP.NET MVC allows "\" in its route parameters.
 
But if you have the default route (/ControllerName/ActionName) enabled, your app could still be vulnerable. A user could pass the parameter as a GET or POST parameter (ie. go to /Gallery/FullImage?id=../../../../../../../etc/passwd) and the default model binder will accept this parameter. It's usually safer to always do validation of your parameters instead of relying on the routing engine to do it :)
 
What I mean is file path validation in 
Response.TransmitFile 
Response.WriteFile 
Server.MapPath 
System.IO.Path.GetFiles 
etc.
To check whether the requested file is not below the root directory of the web application 
But in some cases you might want to read files below the root directory (eg. some apps use c:\Windows\Temp or /tmp)
 
WriteFile.ashx?myfile=../../../../../../../root/.ssh/id_rsa would be really really bad.
This should never work as id_rsa should have its mode set to 0700 and Mono shouldn't be running as root. The user Mono runs as should be relatively locked down. I use www-data (the default web server / PHP-FPM user in Debian) for mine.
 
 
On Mon, Feb 4, 2013 at 12:03 AM, quandary <[hidden email]> wrote:
Remote file inclusion fixed, ashx handlers removed, FullImage removed, website back up.
 
Filed but 10'001
 
 
 
No, I don't mean parameter validation, and RFI can't work in MVC when you request from a browser on Windows, because
parameters are separated by / and windows translates backslash to forwardslash.
(at least not until one uses a catchall parameter), I checked.
 
If you'd use a browser on Linux, I don't know if it would change backslashes into slashes,
which would be a potentially dangerous thing for a windows server.
But I have a Linux server, so who cares about that.
 
It can only work for parameters passed via QueryString/HttpPost, such as in the two ashx handlers I added.
(or if a confidential file is in the same directory, but that would be really stupid).
 
 
What I mean is file path validation in
Response.TransmitFile
Response.WriteFile
Server.MapPath
System.IO.Path.GetFiles
etc.
To check whether the requested file is not below the root directory of the web application
(so that it would throw an AccessDeniedException on TransmitFile).
 
Or in other words,
if( !strFileName.StartsWith(AppDomain.CurrentDomain.BaseDirectory, StringComparer.OrdinalIgnoreCase)
     throw new AccessDeniedException("no access to files below application root directory");
 
of course, the above is not sufficient, because relative paths in absolute paths are possible and supported by .NET/Windows/Linux.
 
Because if that path validation isn't done, one can request (for example in my previous handler)
which makes RFI interesting in the first place.
I checked an it worked, I got /etc/passwd back...
Now /etc/passwd wouldn't be that bad,
since it only contains MD5 hashes (though MD5 is rainbow-table vulnerable) and because I configured ssh to not allow password logins,
but WriteFile.ashx?myfile=../../../../../../../root/.ssh/id_rsa would be really really bad.
 
I think I remember stumbling over such an exception somehow in IIS (perhaps SecurityException and not AccessDenied),
but not on the ASP.NET development server.
 
On 02/03/2013 12:41 PM, Daniel Lo Nigro wrote:
Better I mention it than risking someone more malicious noticing it, since the link was already in a public mailing list. :)
 
Isn't this a mono-bug, too ?
As far as I'm aware, the .NET Framework only validates for HTML tags in parameters. It doesn't validate file paths since it doesn't even know the parameter will be used for a file path (things like "..\" could be valid GET parameters for your page). I don't think there's any built in mechanism to prevent directory traversal.
 
 
 
On Sun, Feb 3, 2013 at 10:34 PM, quandary <[hidden email]> wrote:
Oh wonderful, it's called remote file inclusion.
I suspected that much, but I didn't bother to address it,
because I didn't publish the sources and internal config files - up until today.
 
So with you having mentioned it for all script kiddies to see - site taken down until validation is added.
Before that, I quickly checked - one can access files below the root directory of the web application.
 
Isn't this a mono-bug, too ?
Because I think I remember me having done this once on a test or production server, and it gave a wonderful YSOD on IIS.
 
On 02/03/2013 11:45 AM, Daniel Lo Nigro wrote:
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 vulnerability.
 
 
On Sun, Feb 3, 2013 at 9:38 PM, quandary <[hidden email]> wrote:
Yep, indeed that sounds like that.
And I just tested.
Added WriteFile.ashx and Transmit.ashx
 
and testet with
and
 
 
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.NET handler (.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
}
 
 
 
On Sun, Feb 3, 2013 at 4:00 PM, SirNoSkill <[hidden email]> 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:
 
 
 
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.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 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 <[hidden email]> wrote:
Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
 
More here:
 
 
 
--
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
 
--
SirNoSkill
-- 
http://www.fastmail.fm - mmm... Fastmail...
 
--
SirNoSkill
-- 
http://www.fastmail.fm - The professional email service

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

quandary82
In reply to this post by quandary82
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,
 
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:
 
 
 
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 <[hidden email]> wrote:
Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
 
More here:
 
 
 
--
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
 
--
SirNoSkill
-- 
http://www.fastmail.fm - mmm... Fastmail...
 
--
SirNoSkill
-- 
http://www.fastmail.fm - IMAP accessible web-mail

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

Daniel Lo Nigro
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 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 <[hidden email]> wrote:
Hi,

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

 
 
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,
 
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:
 
 
 
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 <[hidden email]> wrote:
Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
 
More here:
 
 
 
--
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
 
--
SirNoSkill
-- 
http://www.fastmail.fm - mmm... Fastmail...
 
--
SirNoSkill
-- 
http://www.fastmail.fm - IMAP accessible web-mail


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

quandary82
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
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: 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 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 <[hidden email]> wrote:
Hi,
 
I've forwarded the error to the nginx mailing list.
 
 
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,
 
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:
 
 
 
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.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 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 <[hidden email]> wrote:
Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
 
More here:
 
 
 
--
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
 
--
SirNoSkill
-- 
http://www.fastmail.fm - mmm... Fastmail...
 
--
SirNoSkill
-- 
http://www.fastmail.fm - IMAP accessible web-mail
 
--
SirNoSkill
-- 
http://www.fastmail.fm - One of many happy users:
  http://www.fastmail.fm/help/overview_quotes.html

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

quandary82
In reply to this post by Daniel Lo Nigro
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 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 <[hidden email]> wrote:
Hi,

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

 
 
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,
 
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:
 
 
 
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 <[hidden email]> wrote:
Corrected the mime, but seems to be a mono-bug (or fastcgi) anyway.
 
More here:
 
 
 
--
Sent from the Mono - Dev mailing list archive at Nabble.com.
_______________________________________________
Mono-devel-list mailing list
 
--
SirNoSkill
-- 
http://www.fastmail.fm - mmm... Fastmail...
 
--
SirNoSkill
-- 
http://www.fastmail.fm - IMAP accessible web-mail



_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

knocte

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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>>>     <[hidden email] <mailto:[hidden email]>> 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
>>>>         [hidden email]
>>>>         <mailto:[hidden email]>
>>>>         http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>
>>>     --
>>>     SirNoSkill
>>>     [hidden email] <mailto:[hidden email]>
>>>     --
>>>     http://www.fastmail.fm  - mmm... Fastmail...
>>     --
>>     SirNoSkill
>>     [hidden email] <mailto:[hidden email]>
>>
>>     --
>>     http://www.fastmail.fm  - IMAP accessible web-mail
>>
>>
>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> [hidden email]
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug in mono 3.0.1 MVC3 File/FileResult

quandary82
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 <[hidden email]
>>> <mailto:[hidden email]>> 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
>>>>>     <[hidden email] <mailto:[hidden email]>> 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
>>>>>         [hidden email]
>>>>>         <mailto:[hidden email]>
>>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>>>
>>>>     --
>>>>     SirNoSkill
>>>>     [hidden email] <mailto:[hidden email]>
>>>>     --
>>>>     http://www.fastmail.fm  - mmm... Fastmail...
>>>     --
>>>     SirNoSkill
>>>     [hidden email] <mailto:[hidden email]>
>>>
>>>     --
>>>     http://www.fastmail.fm  - IMAP accessible web-mail
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> [hidden email]
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>
> _______________________________________________
> Mono-devel-list mailing list
> [hidden email]
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Loading...