Req #73377 [Fbk->NoF]: Verbose caching instructions by default.

Edit report at https://bugs.php.net/bug.php?id=73377&edit=1 ID: 73377 Updated by: php-bugs@lists.php.net Reported by: inforbano at gmail dot com Summary: Verbose caching instructions by default. -Status: Feedback +Status: No Feedback Type: Feature/Change Request Package: PHP options/info functions PHP Version: Irrelevant Assigned To: cmb Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2021-09-09 15:19:53] cmb@php.net Are you aware that there is an INI setting which you can use to choose the behavior: session.cache_limiter= ------------------------------------------------------------------------ [2016-10-24 22:39:32] 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. :) ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=73377 -- Edit this bug report at https://bugs.php.net/bug.php?id=73377&edit=1