Password-protected pages lacking appropriate 'Cache-Control' request header

[brevilo]

Over the years there have been recurring reports of users having issues with password-protected pages which simply redirected to the password prompt again, instead of the actually protected page (after successful login), e.g.:

• #3445
• #4030
• Four-year-long ​discussion (now closed)

The tickets got closed with "worksforme" and the discussions kept looking at the WP config, plugins or client-side issues, but so far without reliable solutions. Since I myself ran into the same problem as so many others before, I now analyzed it and found the (well, at least a) culprit.

I narrowed it down to be a caching problem at my hosting provider, seemingly using Nginx as a caching reverse-proxy! This could also explain the "worksforme" closures above: if your provider doesn't use such caching (or a CDN for that matter), you won't reproduce it.

In my case the response headers (after the successful) redirect contained:
X-Cache-Status: HIT (see this ​FAQ)

As a workround I now ​send the appropriate header ​tailored for this situation, as part of my theme:

<?php
header('Cache-Control: private');

For me, and probably a lot of others (reverse-proxy caching or CDNs are widely used) the solution would be to do this for all password-protected pages. Remember that header() must be called before any actual output is sent.

Thanks

[brevilo]

Here's ​one of many examples where troubled users switched their provider and the problem was gone. To me this also hints at a reverse-proxy setup. This could really positively affect as lot of installations, I reckon.

[hellofromTonya]

Changing the Version from 6.6 to 2.0.5.