Horray, used mono 3.0.3 stable, and use_chuncked = false; fixed it.
Thanks ! ;)
nginx defines this fastcgi parameter:
fastcgi_paramGATEWAY_INTERFACECGI/1.1;
So here a proper patch (tested - works, maybe add ordinalignorecase to
startswith ?):
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_paramGATEWAY_INTERFACECGI/1.1;
So
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
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
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
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,
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
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
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
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
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
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
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:
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?
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:
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
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
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 http://wiki.nginx.org/XSendfile
18 matches
Mail list logo
