info->status at this point is zero, because file_cache_recall_mydata() does not initialize it.
But setting it properly does not help either. The client gets the bogus 304 no matter what info->status is at this point.
*groan* I really dislike the dobj/cache_info distinction. I'd like to work on unifying it. Oh, well.
| + /* The cached response will override our err_headers_out. */ | + apr_table_clear(r->err_headers_out); | + /* Merge in our headers. */ | + ap_cache_accept_headers(cache->handle, r);
What about r->headers_out here? Does it have to be cleared, too?
Hmm. Yah, I guess it needs to clear it as mod_proxy has already set its response headers in r->headers_out.
It still contains headers which came just in from the upstream server. ap_cache_accept_headers() updates these headers, but does not replace them entirely.
(Not that I have much clue which headers are what here, but I get "Transfer-Encoding: chunked" in the not-chunked-at-all response, so that must have come through from the upstream server.)
Thanks again for the help,
Okay, please try again. =) I've committed fixes in r152973: these should go some way to addressing these problems.
By the way, *many* thanks for being a guinea pig! I had not yet had a chance to even look at the revalidation of content before. It was one of my last major things to do with mod_cache before httpd started the beta cycle. As you can see, it needed some major work. Hopefully, with some patience, we can get these bugs nailed. *sigh*
And, yes, once we know that it is solid in trunk, we'll look at backporting these changes en masse into 2.0.x - but let's try to make sure that we have a working cache in trunk first. =) Thanks! -- justin
