[wp-trac] [WordPress Trac] #61711: Password-protected pages lacking appropriate 'Cache-Control' request header

[WordPress Trac]

#61711: Password-protected pages lacking appropriate 'Cache-Control' request header
--------------------------+-----------------------------
 Reporter:  brevilo       |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  6.6
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 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 [[https://wordpress.org/support/topic/password-protected-
 pages-not-working-5|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 [[https://blog.nginx.org/blog/nginx-
 caching-guide|FAQ]])

 As a workround I now
 [[https://www.php.net/manual/en/function.header.php|send]] the appropriate
 header [[https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-
 Control#directives|tailored]] for this situation, as part of my theme:
 {{{#!php
 <?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

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61711>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform