php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #73377 Verbose caching instructions by default.
Submitted: 2016-10-23 10:38 UTC Modified: 2021-09-19 04:22 UTC
Votes:2
Avg. Score:3.0 ± 0.0
Reproduced:0 of 2 (0.0%)
From: inforbano at gmail dot com Assigned: cmb (profile)
Status: No Feedback Package: PHP options/info functions
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: inforbano at gmail dot com
New email:
PHP Version: OS:

 

 [2016-10-23 10:38 UTC] inforbano at gmail dot com 
Description:
------------
When function session_start(); is used with default options, PHP generates headers like this:

Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache

This verbose behavior is wrong for the following reasons.

Most PHP-programmers do not need to know anything about caching. Therefore user agents (browsers, proxies, robots...) MUST have rational behavior (with respect to caching) without any special instructions from the server. This is only problem of user agents to understand cookies and to automatically adjust their caching behavior according to their needs.

On the other hand, some meticulous PHP-programmers investigate HTTP-headers of their sites to be sure that everything is fine. And in this case they just waste their time to study problems, that are not their.


Test script:
---------------
<?php
session_start();


Expected result:
----------------
No special headers for caching by default.
This is like
session_cache_limiter('');
is set by default.


Actual result:
--------------
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-10-23 10:48 UTC] inforbano at gmail dot com 
What is even worse, according to RFC-2616
https://tools.ietf.org/html/rfc2616#section-14.21
date in Expires: can not be in the past. So, here PHP just violates web-standards.
 [2016-10-24 16:47 UTC] bwoebi@php.net 
You are misreading the RFC, and even RFC 7234 states it's allowed:

https://tools.ietf.org/html/rfc7234#section-5.3
> An origin server [...] MUST NOT generate an Expires field
  unless its value represents a fixed time in the past (always expired)

which is exactly what we want.

…

Regarding the issue, I doubt it's an actual issue, but I leave that to other people to determine.
 [2016-10-24 20:32 UTC] inforbano at gmail dot com 
"[...]" in your citation is "without a clock". Have you seen many servers with PHP engine and without a clock? Anyway, this combination is not typical.

A typical server with PHP has clock. And it automatically generates the Date: header with current time. The Expires: header with time in the past in this situation is spec violation.

The issue is actual, in particular, because it is unclear, how web-crawlers should treat this situation. Formally, they can treat it as "the page contains outdated content". Therefore, rating of the page can be suppressed.
 [2016-10-24 21:03 UTC] rasmus@php.net 
Check section 4.2:

   If an origin server wishes to force a cache to validate every
   request, it can assign an explicit expiration time in the past to
   indicate that the response is already stale.  Compliant caches will
   normally validate a stale cached response before reusing it for
   subsequent requests (see Section 4.2.4).

That has nothing to do with clockless operation and again says that an explicit expiration date in the past is allowed. Plus RFC section 14.21 doesn't contain the sentence you quoted at all. It doesn't say that the expires date cannot be in the past. The only thing it says is:

   To mark a response as "already expired," an origin server sends an
   Expires date that is equal to the Date header value. (See the rules
   for expiration calculations in section 13.2.4.)

which is not the same as saying it cannot be set to an explicit past value, especially since other parts of the RFC explicitly mentions that it can. If you are going to quote RFCs, please quote them directly and don't paraphrase.
 [2016-10-24 22:39 UTC] inforbano at gmail dot com 
Ok. Thank you for the explanation. It looks like you are right: According to RFC 7234 (not RFC 2616?), PHP does not violate web-standards.

Still, I feel that default behavior of PHP here is counter-intuitive and gives rise to unnecessary questions. Brevity is the soul of wit. And this principle is applicable to generation of headers also. :)
 [2021-09-09 15:19 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-09-09 15:19 UTC] cmb@php.net 
Are you aware that there is an INI setting which you can use to
choose the behavior:

  session.cache_limiter=
 [2021-09-19 04:22 UTC] php-bugs at lists dot php dot net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Apr 20 04:01:28 2024 UTC