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.
I've decoupled `Cookie` from the actual act of setting and getting
cookies. Currently there are a few limitations to how Cookie works that
this change mitigates:
0. `Cookie` currently changes the super global `$_COOKIE` when setting
to make the state of an application a bit more managable, but this is
bad because we shouldn't be modifying super globals
0. One can't actually change the `$cookie_class` once the
`Cookie::$inst` has been instantiated
0. One can't test cookies as there is no class that holds the state of
the cookies (it's just held in the super global which is reset as part
of `Director::test()`
0. One can't tell the origin of a cookie (eg: did the application set it
and it needs to be sent, or did we receive it from the browser?)
0. `time()` was used, so testing was made difficult
0. There was no way to get all the cookies at once (without accessing
the super global)
Todos are on the phpdoc and I'd like to write some tests for the backend
as well as update the docs (if there are any) around cookies.
DOCS Adding `Cookie` docs
Explains basic usage of `Cookie` as well as how the `Cookie_Backend`
controls the setting and getting of cookies and manages state of sent vs
received cookies
Fixing `Cookie` usage
`Cookie` is being used inconsistently with the API throughout framework.
Either by not using `force_expiry` to expire cookies or setting them to
null and then expiring them (which is redundant).
NEW `Director::test()` takes `Cookie_Backend` rather than `array` for `$cookies` param
Example: you have a site in a sub-directory off the webroot, you call
->Link() on a SiteTree record, which returns "/[sitedir]/my-page", and
you pass this URL to Director::test(). It's a valid URL, but
Director::test() will throw a 404.
Director::test() should be ensuring that all URLs passed to it are
properly made relative, not just in the case where it thinks the URL
is absolute.
Provides an interface for classes to implement their own flush()
functionality. This function gets called early in a request on
all implementations of Flushable when flush=1|all is requested in the
URL.
This fix came out of an issue where Requirements combined files were not
being cleaned up after dev/build?flush=1, due to the fact that flush
would only occur when you called it while on a page that used those
combined files, but not in any other contexts. This will now call flush
on any implementors of Flushable regardless of the context of where
flush was called.
This was originally added to stop PHP on Windows complaining that it
couldn't garbage collect old sessions, but that was for an old version
of PHP years ago and doesn't seem to be an issue any longer. We
really shouldn't be suppressing this. If session_start() threw a
warning that it couldn't write to the filesystem, then we wouldn't
know about it at all.
