The HTTP Pragma header is obsolete for HTTP 1.1,
and technically only defined for a HTTP request (not response).
Refer to https://www.mnot.net/cache_docs/#PRAGMA
,http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32.
It is superseded by the "Cache-Control" directive.
See HTTP 1.1 spec at https://tools.ietf.org/html/rfc7234#section-5.4:
'Because the meaning of "Pragma: no-cache" in responses is
not specified, it does not provide a reliable replacement for
"Cache-Control: no-cache" in them.'
Sending a "Pragma: nocache" response header is a prudent
backwards compatibility measure for HTTP 1.0 clients.
The intended behaviour is for the majority clients as well as any
intermediary proxies to ignore this header.
Sending an empty Pragma is a known hack
for preventing PHP from adding "Pragma: nocache" to responses
with started sessions (see http://php.net/session_cache_limiter),
since PHP does not allow unsetting existing header() calls.
In some cases, a request may not have an HTTP_USER_AGENT. This should
check the variable exists before attempting to check it. The specific
case where it failed for me was Active Directory Federation Services
sending a web request to a SilverStripe site, but failing because it
doesn't have an agent string.
Currently IE6-8 will refuse to download files over HTTPS with default
Framework settings.
Currently the HTTP::add_cache_headers competely overrides Cache-Control
headers on each request, so there is no way to inject custom headers
from the API-consuning methods.
Also of note: adding no-store header also fixes the issue but will
prevent proxies from caching the request body (which they do when using
no-cache). So the setting max-age to some low number is a better choice
here.
If you have a Varnish box in front of a SilverStripe install, and
you call forceSSL, the Vary header wouldnt get sent. As a result
Varnish would respond with the same redirect reponse after the
redirect, leading to an infinite loop
urlRewriter will expect a callable as a second parameter,
but will work with the current api and simply raise a deprecation error.
HTTP::absoluteURLs now correctly rewrites urls into absolute urls. Resolves introduced in c56a80d6ce
HTTP::absoluteURLs now handles additional cases where urls were not translated.
Test cases for HTTP::absoluteURLs added for both css and attribute links.
Cleaned up replacement expression and improved documentation.
The entire framework repo (with the exception of system-generated files) has been amended to respect the 120c line-length limit. This is in preparation for the enforcement of this rule with PHP_CodeSniffer.
