Re: [users@httpd] Incomplete file downloads if Apache HTTPD is killed
So that was bad way to simulate apachectl stop just because of the above. I think with 2.2 it even is not true, because apache2 has own way to configure shutdown timeouts, the GracefulShutdownTimeout directive. On 09.05.11 16:26, Bostjan Skufca wrote: Yes, timeout is configurable, but that was the only lie there:) well, apache2ctl is here only a scripts that calls apache2 -k ... While talking about killed server and knowing that the file was transferred - It's often impossible to know. The chunked encoding or the Content-Length header are needed to know if the whole file was transfered. Chunked content encoding does not help here. Also, my experiments with few popular browsers has shown that they don't even try to support Content-Length correctly. I've been watching HTTP headers and correct Content-Length was specified, then I started a download and then killed the HTTPD child that served the download request before the download was completed. AND browsers did not even complain about failed download, they just stopped downloading with message Download complete or (if I selected to run the executable) complained about downloaded file being corrupt, but not incomplete. It does not work with gzip and Firefox too, just tried it. Download complete. So here is the question again - is there something one can do with Apache (or Linux/other OS) that will change browser's behaviour in a way that it will report incomplete download to the user? So it appears there in one, but it was reported that clients ignore it :) -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Your mouse has moved. Windows NT will now restart for changes to take to take effect. [OK] - The official User-To-User support forum of the Apache HTTP Server Project. See URL:http://httpd.apache.org/userslist.html for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] Incomplete file downloads if Apache HTTPD is killed
if a server is killed (SIGKILL) during a large static file transfer, then the client is not notified by his browser that file has not been completely downloaded. On Win it just says it is not a valid Win32 application or corrupted or sth. Now I know this is not a general problem and a graceful restart is the way to go around this, but if I do an upgrade then proper restart is required, or at least I think I remember I had problems with graceful restart in such situations. Sending a SIGKILL is an unfriendly way to end a process -- it causes the kernel to immediately terminate the process, without giving the process any chance to clean up. SIGKILL is thus not one of the signals handled specially by Apache HTTP Server. For a list of the signals that are handled specially, see http://httpd.apache.org/docs/2.2/stopping.html On 20.04.11 20:19, Bostjan Skufca wrote: Sending SIGKILL was just a way to simulate apachectl stop, which sends SIGTERM and then if after 10s some children still did not exit, parent sends SIGKILL to them. So that was bad way to simulate apachectl stop just because of the above. I think with 2.2 it even is not true, because apache2 has own way to configure shutdown timeouts, the GracefulShutdownTimeout directive. While talking about killed server and knowing that the file was transferred - It's often impossible to know. The chunked encoding or the Content-Length header are needed to know if the whole file was transfered. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. WinError #9: Out of error messages. - The official User-To-User support forum of the Apache HTTP Server Project. See URL:http://httpd.apache.org/userslist.html for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] Incomplete file downloads if Apache HTTPD is killed
On 9 May 2011 15:44, Matus UHLAR - fantomas uh...@fantomas.sk wrote: So that was bad way to simulate apachectl stop just because of the above. I think with 2.2 it even is not true, because apache2 has own way to configure shutdown timeouts, the GracefulShutdownTimeout directive. Yes, timeout is configurable, but that was the only lie there:) While talking about killed server and knowing that the file was transferred - It's often impossible to know. The chunked encoding or the Content-Length header are needed to know if the whole file was transfered. Chunked content encoding does not help here. Also, my experiments with few popular browsers has shown that they don't even try to support Content-Length correctly. I've been watching HTTP headers and correct Content-Length was specified, then I started a download and then killed the HTTPD child that served the download request before the download was completed. AND browsers did not even complain about failed download, they just stopped downloading with message Download complete or (if I selected to run the executable) complained about downloaded file being corrupt, but not incomplete. It does not work with gzip and Firefox too, just tried it. Download complete. So here is the question again - is there something one can do with Apache (or Linux/other OS) that will change browser's behaviour in a way that it will report incomplete download to the user? Thank you for your time BTW, b. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. WinError #9: Out of error messages. - The official User-To-User support forum of the Apache HTTP Server Project. See URL:http://httpd.apache.org/userslist.html for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org - The official User-To-User support forum of the Apache HTTP Server Project. See URL:http://httpd.apache.org/userslist.html for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
[users@httpd] Incomplete file downloads if Apache HTTPD is killed
Hi all, if a server is killed (SIGKILL) during a large static file transfer, then the client is not notified by his browser that file has not been completely downloaded. On Win it just says it is not a valid Win32 application or corrupted or sth. Now I know this is not a general problem and a graceful restart is the way to go around this, but if I do an upgrade then proper restart is required, or at least I think I remember I had problems with graceful restart in such situations. According to this article http://blogs.msdn.com/b/ieinternals/archive/2011/03/09/browsers-accommodate-incorrect-http-content-length-and-sites-depressingly-depend-on-it.aspx sending RST TCP flag should solve the problem for majority of browsers, but I don't know how to achieve such a behaviour of Apache on Linux. Does anyone know how to work around this issue? Thanks for your answer, b.
Re: [users@httpd] Incomplete file downloads if Apache HTTPD is killed
On April 20, 2011 11:11 , Bostjan Skufca bost...@a2o.si wrote: if a server is killed (SIGKILL) during a large static file transfer, then the client is not notified by his browser that file has not been completely downloaded. On Win it just says it is not a valid Win32 application or corrupted or sth. Now I know this is not a general problem and a graceful restart is the way to go around this, but if I do an upgrade then proper restart is required, or at least I think I remember I had problems with graceful restart in such situations. Sending a SIGKILL is an unfriendly way to end a process -- it causes the kernel to immediately terminate the process, without giving the process any chance to clean up. SIGKILL is thus not one of the signals handled specially by Apache HTTP Server. For a list of the signals that are handled specially, see http://httpd.apache.org/docs/2.2/stopping.html If you'd like to completely stop Apache HTTP Server so you can manually restart it later, then sending SIGWINCH will cause httpd to exit gracefully after completing any current requests or after GracefulShutdownTimeout is reached, whichever comes first. Alternatively, you can cause httpd to exit more quickly, interrupting any current requests, by sending it a SIGTERM. I don't know for sure if either of these will cause a TCP RST to be sent to the client, but I think the odds are better than if you used a SIGKILL. -- Mark Montague m...@catseye.org - The official User-To-User support forum of the Apache HTTP Server Project. See URL:http://httpd.apache.org/userslist.html for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] Incomplete file downloads if Apache HTTPD is killed
if a server is killed (SIGKILL) during a large static file transfer, then the client is not notified by his browser that file has not been completely downloaded. On Win it just says it is not a valid Win32 application or corrupted or sth. Now I know this is not a general problem and a graceful restart is the way to go around this, but if I do an upgrade then proper restart is required, or at least I think I remember I had problems with graceful restart in such situations. Sending a SIGKILL is an unfriendly way to end a process -- it causes the kernel to immediately terminate the process, without giving the process any chance to clean up. SIGKILL is thus not one of the signals handled specially by Apache HTTP Server. For a list of the signals that are handled specially, see http://httpd.apache.org/docs/2.2/stopping.html Sending SIGKILL was just a way to simulate apachectl stop, which sends SIGTERM and then if after 10s some children still did not exit, parent sends SIGKILL to them. If you'd like to completely stop Apache HTTP Server so you can manually restart it later, then sending SIGWINCH will cause httpd to exit gracefully after completing any current requests or after GracefulShutdownTimeout is reached, whichever comes first. Alternatively, you can cause httpd to exit more quickly, interrupting any current requests, by sending it a SIGTERM. I don't know for sure if either of these will cause a TCP RST to be sent to the client, but I think the odds are better than if you used a SIGKILL. Thanks for the hint, SIGWINCH (or apachectl graceful-stop) does the trick. I still have to test it (namely if HTTPD with PHP and eAccelerator has any troubles being restarted that way) but this looks promising. Again, RTFM would be my friend - again:) Thanks again, b.
