[Mono-dev] Bug in mono 3.0.1 MVC3 File/FileResult
quandary
quandary82 at hailmail.net
Sun Feb 3 10:38:54 UTC 2013
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
> <http://ASP.NET> handler (.ashx) and see if they also don't work.
>
> 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.
>
> I'd still suggest letting Nginx serve your static files. Just because
> the site is low-traffic doesn't mean that little performance tweaks
> aren't good :). I do something like this:
> location / {
> # Pass requests for unknown files to Mono
> try_files $uri @mono;
> }
>
> location @mono {
> # Put all your Mono config here
> }
> My full site config is at
> https://github.com/Daniel15/Website/blob/master/nginx.conf
>
>
>
> On Sun, Feb 3, 2013 at 4:00 PM, SirNoSkill <quandary82 at hailmail.net
> <mailto:quandary82 at hailmail.net>> wrote:
>
> I have more details on the bug.
> The extra bytes that are at the beginning
>
> |3139366236380D0A|
>
> ||which reads 196b68/r/n in ASCII
> 196b68 is the filesize of the original image in hex...
> All details + hexdump links added here:
> http://stackoverflow.com/questions/14662795/why-do-i-have-unwanted-extra-bytes-at-the-beginning-of-image
> All traffic to that URL [www.daniel-steiger.ch
> <http://www.daniel-steiger.ch>] (except for the folders /doc and
> /images), but including images in /Content, is directly forwarded
> to fastcgi by nginx, as per fastcgi config file for domain.
> server {
> listen 80;
> server_name www.daniel-steiger.ch
> <http://www.daniel-steiger.ch> daniel-steiger.ch
> <http://daniel-steiger.ch>;
> access_log /var/log/nginx/daniel-steiger.ch.access.log;
> location / {
> root /home/danillo/www/HomePage;
> #index index.html index.htm default.aspx
> Default.aspx;
> #fastcgi_index Default.aspx;
> fastcgi_pass 127.0.0.1:9000 <http://127.0.0.1:9000>;
> include /etc/nginx/fastcgi_params;
> }
> location /doc {
> root /usr/share;
> autoindex on;
> allow 127.0.0.1;
> deny all;
> }
> location /images {
> root /usr/share;
> autoindex off;
> }
> #error_page 404 /404.html;
> # redirect server error pages to the static page /50x.html
> #
> error_page 500 501 503 504 /50x.html;
> location = /50x.html {
> root /home/danillo/www/HomePage;
> }
> error_page 502 /502.html;
> location = /502.html {
> root /home/danillo/www/HomePage;
> }
> }
> It's sufficient to have the file served without FileResult.
> Of course it's more efficient if nginx serves it directly, but
> this is a very low traffic website, so performance is really not
> my problem ;)
> And by the way, the problem is not finding a workaround.
> I have already fixed it with a workaround about a week ago.
> I really just want to know where the bug is, because if FileResult
> malfunctions, there's probably more to it, and I don't want to
> walk into a subtle not at the first sight spottable bug later,
> like a botched binary upload/download file.
> On Sat, Feb 2, 2013, at 06:51 AM, Daniel Lo Nigro wrote:
>> Hmm... Maybe try an X-Accel-Redirect header instead. This lets
>> Nginx serve the file instead of Mono having to serve it, which
>> makes it more efficient. See if that makes a difference, or if it
>> has the same issue.
>> Why not just link directly to the file, instead of serving it
>> through your C# code?
>> On Sun, Feb 3, 2013 at 1:43 AM, quandary82
>> <quandary82 at hailmail.net <mailto:quandary82 at hailmail.net>> wrote:
>>
>> Corrected the mime, but seems to be a mono-bug (or fastcgi)
>> anyway.
>> More here:
>> http://stackoverflow.com/questions/14662795/why-do-i-have-unwanted-extra-bytes-at-the-beginning-of-image
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/Bug-in-mono-3-0-1-MVC3-File-FileResult-tp4658382p4658422.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> <mailto:Mono-devel-list at lists.ximian.com>
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
> --
> SirNoSkill
> quandary82 at hailmail.net <mailto:quandary82 at hailmail.net>
>
> --
> http://www.fastmail.fm - mmm... Fastmail...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130203/adeb1834/attachment-0001.html>
More information about the Mono-devel-list
mailing list