httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [PATCH] ETags and Last-Modified, take 3
Date Thu, 04 Sep 1997 15:34:35 GMT
On Thu, 4 Sep 1997, Roy T. Fielding wrote:

> >I'll repeat again ... the server does kill CGIs.  They are killed as soon
> >as the pool is cleared, whether that be because it was a HEAD and the
> >headers have been read and sent to the client, or because it's anything
> >else and a timeout occurs.  It is not trivial to "fix" this.  I don't even
> >think it needs "fixing".  I don't understand people's reluctance to kill
> >CGIs.  They are sent SIGTERM as soon as their pool is cleared, and SIGKILL
> >if they haven't died within three seconds.  It's always been this way. 
> 
> Yes, I know, and it has always been wrong.  If the CGI script closes the
> output and then does some cleanup, it can be killed during the cleanup
> and the server has screwed things for no good reason.  It is utterly
> nuts for the server to assume the CGI is broken just because the process
> is still active after it sends the response.  If the CGI is broken,
> it should twist on the vine until the webmaster notices that it is broken
> and fixes the bloody thing.  Otherwise, the server will appear to randomly
> corrupt databases and similar gateways when the load is high.

Scripts can catch SIGTERM and SIGPIPE and clean up.  The 3 seconds could
be made configurable to avoid sending the SIGKILL until later, but I
personally want my server resources reclaimed automatically.  If a script
really takes a long time for cleanup (which would be absolutely dumb, such
a site couldn't handle any amount of load if a script takes more than 3
seconds to clean up every time it's run) then it can fork itself and do
the cleanup in its child. 

Until/unless we start putting in asychronous cleanups then this sort of
crap ties up a process slot for longer than necessary.

Natrually the CGI "standard" is silent on these things. 

> >> Also, an Etag must include a control stamp which is guaranteed to change
> >> when any part of the content of the response would change.  That is
> >> definitely not the case for the suggested change to mod_include.c, so
> >> you'll have to remove that.
> >
> >I think I missed this ... what change to mod_include? 
> 
> The last part included the addition of set_etag in mod_include if the
> xbithack is on, which is bad.

Then this is probably a bug in 1.2 since set_last_modified() adds etags to
xbithacked documents. 

Dean


Mime
View raw message