I think it will be all right provided the feature is disabled by
default and, as you say, the potential security issue is documented.
On Jan 28, 2008 1:28 PM, Akins, Brian [EMAIL PROTECTED] wrote:
On 1/28/08 4:35 AM, Ivan Ristic [EMAIL PROTECTED] wrote:
The FastCGI process is likely to be
On Jan 25, 2008 7:55 PM, Akins, Brian [EMAIL PROTECTED] wrote:
I started to play with xsendfile more. I noticed the mod_xsendfile floating
around tried to basically replace what the default handler does very well.
Basically, my version does a subrequest for the file. This allows things
like
On Jan 25, 2008, at 3:40 PM, Akins, Brian wrote:
On 1/25/08 3:33 PM, André Malo [EMAIL PROTECTED] wrote:
I'm not sure if a filter is semantically the right place. IMHO
that smells a
bit problematic. It might be better to I'd rather hack that into a
function
similar to ap_internal_redirect
On 1/28/08 4:35 AM, Ivan Ristic [EMAIL PROTECTED] wrote:
The FastCGI process is likely to be running under a different
account, but here we have a facility that allows that other process to
use the privileges of the Apache user to fetch a file. I can see how
this feature could easily find its
On Fri, 25 Jan 2008, Akins, Brian wrote:
X-sendfile is already in the wild and supported by a number of backends.
I don't have strong feeling as to how it is implemented within httpd, but
the subrequest gives a lot of flexibility to it, like using deflate, running
SSI on php output, etc.
On Sun, 27 Jan 2008, Colm MacCarthaigh wrote:
On Sun, Jan 27, 2008 at 10:46:12AM +0100, Niklas Edmundsson wrote:
Using subrequests means that mod_cache won't bite, right? At least
that's the reason for mod_ftp-requests not being handled by the cache
from what I've understood.
This seems like
* Akins, Brian wrote:
On 1/25/08 3:51 PM, André Malo [EMAIL PROTECTED] wrote:
I don't recommend doing that as it contains a race condition (the file
might be changed in the meantime).
That race is in the default_handler as well, isn't it?
Yes. IIRC there's already a bug report for it.
On 1/25/08 3:51 PM, André Malo [EMAIL PROTECTED] wrote:
I don't recommend doing that as it contains a race condition (the file might
be changed in the meantime).
That race is in the default_handler as well, isn't it? It creates a file
bucket based on the size of an earlier stat. So, we are
* Akins, Brian wrote:
On 1/25/08 3:33 PM, André Malo [EMAIL PROTECTED] wrote:
If it should not
be chunked, the backend simply has to provide a content-length along
with the x-sendfile header.
Okay, I add ap_set_content_length(r, sub-finfo.size) and that fixes
it and does not chunk.
I
On 1/25/08 3:33 PM, André Malo [EMAIL PROTECTED] wrote:
If it should not
be chunked, the backend simply has to provide a content-length along with
the x-sendfile header.
Okay, I add ap_set_content_length(r, sub-finfo.size) and that fixes it
and does not chunk.
--
Brian Akins
Chief
On 1/25/08 3:33 PM, André Malo [EMAIL PROTECTED] wrote:
I'm not sure if a filter is semantically the right place. IMHO that smells a
bit problematic. It might be better to I'd rather hack that into a function
similar to ap_internal_redirect and let it call explicitly. That way you'd
need to
* Akins, Brian wrote:
I started to play with xsendfile more. I noticed the mod_xsendfile
floating around tried to basically replace what the default handler does
very well.
Basically, my version does a subrequest for the file. This allows things
like Deny from all, etc, to work. This
I started to play with xsendfile more. I noticed the mod_xsendfile floating
around tried to basically replace what the default handler does very well.
Basically, my version does a subrequest for the file. This allows things
like Deny from all, etc, to work. This should be more secure, ie, if
13 matches
Mail list logo
