4 ms·

The really nasty trick is that when all is done I redirect the browser to the same url and this time I'm sure it will find it. This is a pretty nasty trick (se

The really nasty trick is that when all is done I redirect the browser to the same url and this time I'm sure it will find it. This is a pretty nasty trick (seems like a risk of a redirect loop if the file can't be written), but unnecessary. You can emit content out of the script used for ErrorDocument the same as you can with a CGI. So you generate the content, write it to the filesystem, emit a "Status: 200" header, which replaces the 404 status apache was going to generate, then send a content-type and the generated content in the response body. Your way may be easier if you have complex cache control or expires headers that apache is configured to ad to static files but not dynamically generated content, since the client is only ever given the file by apache directly from the filesystem. I've never used that though.

drusenko 17y ago
we use this exact approach to generate all of our blog pages. incredibly efficient. the twist we use to handle race conditions is to create a lock file. if the 404 handler is called and the lock file exists, someone else is generating that page as we speak -- it goes into a timed loop to check for the file being available. when found, it serves it directly with the 200 header, like you mentioned. we have a maximum loop value (a second, i think) -- if you hit that, it means the other process died for some reason, and never deleted the lock or the page. in that case, generate and write the page yourself, and remove the lock. all future requests are served off of the file system. one nice part of this caching mechanism is that to remove the cache, you just rm -rf the blog directory. tada!
jacquesm 17y ago
No risk of a loop, the file is guaranteed to exist when it's done, the redirect happens just after the fclose on the 'write' (and only if the file is written successfully). That way the browser will see the exact same headers it would on a request where the file did exist.

drusenko 17y ago

we use this exact approach to generate all of our blog pages. incredibly efficient. the twist we use to handle race conditions is to create a lock file. if the 404 handler is called and the lock file exists, someone else is generating that page as we speak -- it goes into a timed loop to check for the file being available. when found, it serves it directly with the 200 header, like you mentioned. we have a maximum loop value (a second, i think) -- if you hit that, it means the other process died for some reason, and never deleted the lock or the page. in that case, generate and write the page yourself, and remove the lock. all future requests are served off of the file system. one nice part of this caching mechanism is that to remove the cache, you just rm -rf the blog directory. tada!

jacquesm 17y ago

No risk of a loop, the file is guaranteed to exist when it's done, the redirect happens just after the fclose on the 'write' (and only if the file is written successfully). That way the browser will see the exact same headers it would on a request where the file did exist.