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 <quandar...@hailmail.net
<mailto:quandar...@hailmail.net>> wrote:
Hi,
I've forwarded the error to the nginx mailing list.
http://forum.nginx.org/read.php?2,235985,235988#msg-235988
The response I got:
It's bad idea to use "Transfer-Encoding" while working via CGI and
derived protocols like FastCGI. Quote from RFC 3875,
http://tools.ietf.org/html/rfc3875#section-6.3.4:
The script MUST NOT return any header fields that relate to
client-side communication issues and could affect the server's
ability to send the response to the client.
As you are talking to nginx via FastCGI, not HTTP, it won't try to
dig into content returned and decode it according to any
Transfer-Encoding. Instead, the "Transfer-Encoding" header
returned will be just dropped by nginx as per RFC 3875.
On Sat, Feb 2, 2013, at 09:00 PM, SirNoSkill wrote:
I have more details on the bug.
The extra bytes that are at the beginning
|3139366236380D0A|
||which reads 196b68/r/n in ASCII
196b68 is the filesize of the original image in hex...
All details + hexdump links added here:
http://stackoverflow.com/questions/14662795/why-do-i-have-unwanted-extra-bytes-at-the-beginning-of-image
All traffic to that URL [www.daniel-steiger.ch
<http://www.daniel-steiger.ch>] (except for the folders /doc and
/images), but including images in /Content, is directly forwarded
to fastcgi by nginx, as per fastcgi config file for domain.
server {
listen 80;
server_name www.daniel-steiger.ch
<http://www.daniel-steiger.ch> daniel-steiger.ch
<http://daniel-steiger.ch>;
access_log /var/log/nginx/daniel-steiger.ch.access.log;
location / {
root /home/danillo/www/HomePage;
#index index.html index.htm default.aspx
Default.aspx;
#fastcgi_index Default.aspx;
fastcgi_pass 127.0.0.1:9000
<http://127.0.0.1:9000>;
include /etc/nginx/fastcgi_params;
}
location /doc {
root /usr/share;
autoindex on;
allow 127.0.0.1;
deny all;
}
location /images {
root /usr/share;
autoindex off;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 501 503 504 /50x.html;
location = /50x.html {
root /home/danillo/www/HomePage;
}
error_page 502 /502.html;
location = /502.html {
root /home/danillo/www/HomePage;
}
}
It's sufficient to have the file served without FileResult.
Of course it's more efficient if nginx serves it directly, but
this is a very low traffic website, so performance is really not
my problem ;)
And by the way, the problem is not finding a workaround.
I have already fixed it with a workaround about a week ago.
I really just want to know where the bug is, because if
FileResult malfunctions, there's probably more to it, and I don't
want to walk into a subtle not at the first sight spottable bug
later, like a botched binary upload/download file.
On Sat, Feb 2, 2013, at 06:51 AM, Daniel Lo Nigro wrote:
Hmm... Maybe try an X-Accel-Redirect header instead. This lets
Nginx serve the file instead of Mono having to serve it, which
makes it more efficient. See if that makes a difference, or if
it has the same issue.
Why not just link directly to the file, instead of serving it
through your C# code?
On Sun, Feb 3, 2013 at 1:43 AM, quandary82
<quandar...@hailmail.net <mailto:quandar...@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@lists.ximian.com
<mailto:Mono-devel-list@lists.ximian.com>
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
SirNoSkill
quandar...@hailmail.net <mailto:quandar...@hailmail.net>
--
http://www.fastmail.fm - mmm... Fastmail...
--
SirNoSkill
quandar...@hailmail.net <mailto:quandar...@hailmail.net>
--
http://www.fastmail.fm - IMAP accessible web-mail
