Bug in mono 3.0.1 MVC3 File/FileResult
Locked
Bug in mono 3.0.1 MVC3 File/FileResult
 
|
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 |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
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:
_______________________________________________ Mono-devel-list mailing list [hidden email] http://lists.ximian.com/mailman/listinfo/mono-devel-list |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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 |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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. _______________________________________________ Mono-devel-list mailing list [hidden email] http://lists.ximian.com/mailman/listinfo/mono-devel-list |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
I have more details on the bug.
The extra bytes that are at the beginning
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:
--
SirNoSkill
-- http://www.fastmail.fm - mmm... Fastmail... _______________________________________________ Mono-devel-list mailing list [hidden email] http://lists.ximian.com/mailman/listinfo/mono-devel-list |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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 }
My full site config is at https://github.com/Daniel15/Website/blob/master/nginx.conf On Sun, Feb 3, 2013 at 4:00 PM, SirNoSkill <[hidden email]> wrote:
_______________________________________________ Mono-devel-list mailing list [hidden email] http://lists.ximian.com/mailman/listinfo/mono-devel-list |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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:
_______________________________________________ Mono-devel-list mailing list [hidden email] http://lists.ximian.com/mailman/listinfo/mono-devel-list |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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:
_______________________________________________ Mono-devel-list mailing list [hidden email] http://lists.ximian.com/mailman/listinfo/mono-devel-list |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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:
_______________________________________________ Mono-devel-list mailing list [hidden email] http://lists.ximian.com/mailman/listinfo/mono-devel-list |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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.
.NET request validation: http://msdn.microsoft.com/en-us/library/hh882339.aspx
On Sun, Feb 3, 2013 at 10:34 PM, quandary <[hidden email]> wrote:
_______________________________________________ Mono-devel-list mailing list [hidden email] http://lists.ximian.com/mailman/listinfo/mono-devel-list |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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:
_______________________________________________ Mono-devel-list mailing list [hidden email] http://lists.ximian.com/mailman/listinfo/mono-devel-list |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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 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:
_______________________________________________ Mono-devel-list mailing list [hidden email] http://lists.ximian.com/mailman/listinfo/mono-devel-list |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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:
--
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 |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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:
--
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 |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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:
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:
_______________________________________________ Mono-devel-list mailing list [hidden email] http://lists.ximian.com/mailman/listinfo/mono-devel-list |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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:
--
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 |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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:
_______________________________________________ Mono-devel-list mailing list [hidden email] http://lists.ximian.com/mailman/listinfo/mono-devel-list |
|
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 |
Re: Bug in mono 3.0.1 MVC3 File/FileResult
|
|
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 |
«
Return to Mono - Dev
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |