Mailing List Archive

[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962

Christophe JAILLET <christophe.jaillet@wanadoo.fr> changed:

What |Removed |Added
----------------------------------------------------------------------------
Keywords| |PatchAvailable

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files [ In reply to ]
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962

Joe Orton <jorton@redhat.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |mmd.osm@gmail.com

--- Comment #3 from Joe Orton <jorton@redhat.com> ---
*** Bug 64834 has been marked as a duplicate of this bug. ***

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files [ In reply to ]
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962

Joe Orton <jorton@redhat.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |alex@envivio.com

--- Comment #4 from Joe Orton <jorton@redhat.com> ---
*** Bug 47693 has been marked as a duplicate of this bug. ***

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files [ In reply to ]
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962

--- Comment #5 from Joe Orton <jorton@redhat.com> ---
The problem here is that we're calling fstat() again for every request in the
critical path of serving a GET request. I don't know how much performance
difference this will make on a modern server, but assume it is non-zero.

If we're going to do this it should be right after the open() so the mtime used
is using correct stat data as well (and etag).

The trade-off is whether we should fix correctness for an edge case, but make
everybody take a performance hit.

I think it should be possible to offer a "fast" equivalent of the default
handler, i.e. without the extra fstat(), with some option/config tweak applied,
BUT:

1. we can only do so by omitting Last-Modified, etag, and content-length, since
all may be using stale stat data from the directory walk.

2. we could not use the FILE bucket, which needs a determinate length (hence
requires stat data), so we would lose the performance benefits sending the
content via mmap() or sendfile() etc so it might not actually be faster (I have
no idea)

3. for small files without a C-L, the content-length filter will still be able
to generate a content-length even by reading till EOF, but not for larger
files, so there is a performance/network efficiency hit here too.

I tend towards saying we should fix correctness at the cost of performance
regardless, and probably the second-fstat-less path isn't worth the
complexity/costs.

(The "proper" solution is to open the file then fstat in the dirwalk, then use
the fd in the default handler, I have no idea how we can do it without huge
hacks or some redesign of the core hooks, since we don't know which handler
will be used in the dirwalk. I may be missing other fundamental things.)

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files [ In reply to ]
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962

--- Comment #6 from Ruediger Pluem <rpluem@apache.org> ---
(In reply to Joe Orton from comment #5)
> The problem here is that we're calling fstat() again for every request in
> the critical path of serving a GET request. I don't know how much
> performance difference this will make on a modern server, but assume it is
> non-zero.
>
> If we're going to do this it should be right after the open() so the mtime
> used is using correct stat data as well (and etag).
>
> The trade-off is whether we should fix correctness for an edge case, but
> make everybody take a performance hit.
>
> I think it should be possible to offer a "fast" equivalent of the default
> handler, i.e. without the extra fstat(), with some option/config tweak
> applied, BUT:
>
> 1. we can only do so by omitting Last-Modified, etag, and content-length,
> since all may be using stale stat data from the directory walk.
>
> 2. we could not use the FILE bucket, which needs a determinate length (hence
> requires stat data), so we would lose the performance benefits sending the
> content via mmap() or sendfile() etc so it might not actually be faster (I
> have no idea)
>
> 3. for small files without a C-L, the content-length filter will still be
> able to generate a content-length even by reading till EOF, but not for
> larger files, so there is a performance/network efficiency hit here too.
>
> I tend towards saying we should fix correctness at the cost of performance
> regardless, and probably the second-fstat-less path isn't worth the
> complexity/costs.

+1

>
> (The "proper" solution is to open the file then fstat in the dirwalk, then
> use the fd in the default handler, I have no idea how we can do it without
> huge hacks or some redesign of the core hooks, since we don't know which
> handler will be used in the dirwalk. I may be missing other fundamental
> things.)

The idea to fix it that way instead of with the proposed patch to the default
handler is to avoid similar issues for other handlers and having it to fix
there over and over again? I agree this could be tricky to fix in the dirwalk.
Maybe an additional fd field in request_rec? But this would mean we would
always open the file regardless if the handler needs it or uses our fd.
I guess this is better discussed on dev@ than here.

--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org