Hi everyone!

I am debugging some issues in a nginx (big fan!) -> Apache proxy cache setup.

I need to understand at what point is a page marked as being in the cache during the lifecycle of a web request.

I am working with the Apache mod_pagespeed PURGE setup. This signals nginx via a cache PURGE as soon as a better, more optimized version of a page is available.

The bug I am experiencing is that PURGES seem to work for some pages and not for other. I believe this is because a page may be PURGEd before it is marked as cached.

At what point during a request is the page cached?

1. Web client -> 2. tcp connection to nginx -> 3. page request -> 4. cache MISS -> 5. sub proxy request to apache -> 6. tcp connection to Apache host -> 7. page request -> 8. page response -> 9. proxy pass connection closed -> 10. page response returned to web client -> 11 web client connection closed -> 12 nginx logs acces_logs

Is the page considered to be in the nginx cache as a HIT at step 8, 9, 10, 11 or 12?

Below is my theory on why some cache purge requests (if made too quick) fail from mod_pagespeed. Does this hold true?

1. a web client connects to nginx
2. a page is requested
3. the page is a MISS (not in cache)
4. Nginx does a sub proxy request to Apache to fetch the page
4a. a tcp connection is established (nginx -> Apache)
4b. request sent
4c. response received
4d. mod_pagespeed (via a new, separate connection) issues a PURGE back to nginx
i) cache purge requested via GET/PURGE
ii) PAGE NOT IN CACHE (until point 4g.)
iii) connection closed
iv) PURGE request access_logged with 404
4e. proxy connection is closed
4f. Nginx logs the access_log
4g. Nginx saves / marks page as cached.
5. if step 4d. is repeated here, the PURGE would work (200).

Thank you,

Luci