Req #73377 [Com]: Verbose caching instructions by default.

From: Date: Mon, 24 Oct 2016 22:39:35 +0000
Subject: Req #73377 [Com]: Verbose caching instructions by default.
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-204992@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=73377&edit=1 ID: 73377 Comment by: inforbano at gmail dot com Reported by: inforbano at gmail dot com Summary: Verbose caching instructions by default. Status: Open Type: Feature/Change Request Package: PHP options/info functions PHP Version: Irrelevant Block user comment: N Private report: N New Comment: 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. :) Previous Comments: ------------------------------------------------------------------------ [2016-10-24 21:03:34] 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 20:32:14] 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 16:47:09] 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-23 10:48:41] 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-23 10:38:38] 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 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=73377&edit=1

« previous php.bugs (#204992) next »