I completely agree. So much even that I just committed it (r156306). Why are we storing the header fd in the disk object anyways? I haven't gone through mod_disk_cache.c yet, but at least for store_headers() it doesn't seem to make any sense.
It's not really the 'disk' object per se - it's part of mod_disk_cache's private cache handle. When we open the cache handle, we also open the associated file descriptors in open_entity to ensure that we have something valid cached. We then use those open descriptors in recall_headers and recall_body later on.
Note that we're a little tricky and we partially read the header file in open_entity to get some meta-data via file_cache_recall_mydata, but we hold off parsing the full MIME headers from disk until recall_headers time.
When it comes to store_headers(), shouldn't that be done using a temp file and moving it into place atomically just like store_body? Are we relying on OS buffering and header size being small enough to pull that off? Or am I just being paranoid? :)
Yes, there's probably a race condition here. However, store_headers is only called once, so the window is relatively small compared to store_body which can be called multiple times. Feel free to have at it. ;-) -- justin