From new-httpd-owner@apache.org Thu Sep 4 08:34:18 1997 Received: (from majordom@localhost) by hyperreal.org (8.8.5/8.8.5) id IAA29318; Thu, 4 Sep 1997 08:34:18 -0700 (PDT) Received: from twinlark.arctic.org (twinlark.arctic.org [204.62.130.91]) by hyperreal.org (8.8.5/8.8.5) with SMTP id IAA29314 for ; Thu, 4 Sep 1997 08:34:15 -0700 (PDT) Received: (qmail 7942 invoked by uid 500); 4 Sep 1997 15:34:35 -0000 Date: Thu, 4 Sep 1997 08:34:35 -0700 (PDT) From: Dean Gaudet To: new-httpd@apache.org Subject: Re: [PATCH] ETags and Last-Modified, take 3 In-Reply-To: <9709040152.aa15363@paris.ics.uci.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org 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