[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962 --- Comment #8 from lewishamilton --- The Content-Length header indicates the size of the message body, in bytes, sent to the recipient. If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding. https://retrobowl-college.io -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962 --- Comment #7 from Trey Wayne --- (In reply to Ståle Kristoffersen from comment #1) > Created attachment 37131 [details] > small program to provoke the error > https://slopegame3d.com > This program, compiled with gcc -o loop test.c will generate random length > files. > The file "/usr/local/apache2/htdocs/test.txt" will be swapped out > atomically, and will always be consistent on disk with the end of the file > be the line "End of file!\n". > > When fetching this through the latest Apache (compiled from > httpd-2.4.41.tar.gz, apr-1.7.0.tar.gz and apr-util-1.6.1.tar.gz) it > sometimes works as expected, sometimes I get a partial file (but the last > line is then always "Lorem ipsum d", which is the same length as "End of > line!\n"). +1 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962 mnalis-sa...@voyager.hr changed: What|Removed |Added CC||mnalis-sa...@voyager.hr -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962 --- Comment #6 from Ruediger Pluem --- (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-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962 --- Comment #5 from Joe Orton --- 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-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962 Joe Orton changed: What|Removed |Added CC||mmd@gmail.com --- Comment #3 from Joe Orton --- *** 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-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962 Joe Orton changed: What|Removed |Added CC||a...@envivio.com --- Comment #4 from Joe Orton --- *** 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-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[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 changed: What|Removed |Added Keywords||PatchAvailable -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962 --- Comment #2 from Ståle Kristoffersen --- Created attachment 37135 --> https://bz.apache.org/bugzilla/attachment.cgi?id=37135=edit This patch solves the problem for me by getting the size from the open file descriptor. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
[Bug 54962] Apache will set incorrect Content-Length header and may serve partial files
https://bz.apache.org/bugzilla/show_bug.cgi?id=54962 Ståle Kristoffersen changed: What|Removed |Added CC||staal...@gmail.com --- Comment #1 from Ståle Kristoffersen --- Created attachment 37131 --> https://bz.apache.org/bugzilla/attachment.cgi?id=37131=edit small program to provoke the error This program, compiled with gcc -o loop test.c will generate random length files. The file "/usr/local/apache2/htdocs/test.txt" will be swapped out atomically, and will always be consistent on disk with the end of the file be the line "End of file!\n". When fetching this through the latest Apache (compiled from httpd-2.4.41.tar.gz, apr-1.7.0.tar.gz and apr-util-1.6.1.tar.gz) it sometimes works as expected, sometimes I get a partial file (but the last line is then always "Lorem ipsum d", which is the same length as "End of line!\n"). -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
