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 setting the content
length to what the core handler thinks it is anyway. The bucket is that
"long."
>From default_handler:
ap_set_content_length(r, r->finfo.size);
e = apr_bucket_file_create(fd, 0, (apr_size_t)r->finfo.size,
r->pool, c->bucket_alloc);
The finfo here is from map_to_storage (directory_walk??) which happened
before...
In theory to avoid this, we could get_file_info on the open handle. That
would need to be changed in default_handler.
(That's one of the reasons I like my approach, we just rely on the
features/bugs of the core. Fix/enhance that and everyone benefits. )
> By backend I meant here the script providing
> the x-sendfile header. That's the only place knowing the behaviour of the
> file exactly.
In theory, if backend gives us an x-sendfile, it shouldn't touch it.
Especially if it's a x-sendfile-temp (lighttpd calls this something
strange).
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
