So I just submitted my first core patch, followed quick by several revisions. It felt as good as I was told it would. Still tingling.

Anyways, this is an issue that's got to be resolved--it's been stuck for months on one particular problem, which I don't think should be a problem at all. It's very problematic for developers of large scale sites to be unable to adjust the expiration sent by Drupal to the client. My goal in this patch is to give developers this ability and intentionally not address the issue--which, again, has delayed this patch for months--of how reverse proxies are going to deal with it. That's not Drupal's job--it's the job of whoever is connecting Drupal with the reverse proxy, and any attempt to solve this on the Drupal Core level will require not using PHP Sessions for users that aren't authenticated. Turn the page for the proof.

Consider this:

1. Drupal can't discard sessions for anonymous users. How would shopping carts work?
2. If we have the session cookie, we can't use Vary: Cookie in the response header (established in issue thread).
3. If we can't use Vary: Cookie, we can't control how proxies will deal with the situation where users log in after browsing the site and accumulating pages in their cache.
4. But individual developers controlling reverse proxies can configure an individual proxy to *not* forward on caching policies to individual browsers or forward proxies, or they can configure their site to redirect authenticated users to a different domain (e.g. www2.mysite.com). Either method will work, and neither can be achieved by any core patch, no matter how transcendentally amazing.
5. But that requires sending proper caching headers from Drupal.
6. But that requires a core patch.

The only difference between my patch and kbahey's original patch is that mine implements a hook to which allows modules to control caching on a per-URL level and his implements this ability via a system setting on a site-wide level. I think it's better and more powerful to do it per-URL. For instance, I want to proxy blocks (e.g., top stories) with 300 second caching using AHAH--that's a contrib module I'm building right now for the new Observer.com, and is why I patched drupal_page_header as well as drupal_page_cache_header. I also want to serve recent articles with 600 second caching, and month-old articles with 86400 second caching. I also need to implement the ability to purge content from the CDN on hook_nodeapi, so I'm writing a module anyways--so will most users of CDNs. One caching setting won't work for a site like Observer.com.

But that isn't actually the cross I'm bearing. I care more about getting this issue unstuck: it shouldn't be Drupal's problem to assume anything about the existence of proxies between the server and the client, because Drupal isn't in a position to solve the problem. But that's not a good enough reason to continue this delay.

Thoughts?