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.
- Updated AspectProxyService to handle multiple handlers for each proxied
object's methods.
- Changed BeforeCallAspect to allow for providing a return value that
should be returned to the caller instead of the proxied return value
- Changed AfterCallAspect behaviour to allow for returning the value of
the aspect to the caller instead of the proxied return value
When the email sender makes the links absolute, it can't handle empty `href` or `src` attributes as there's no expectation that the string length could be 0
BUG Fix incompatibility in Member_GroupList
Fix regressions in merges from 3.1
BUG Fix Security failing on test classes
BUG Fix postgresql compatibility
Clarify sql encoding of table names
Database abstraction broken up into controller, connector, query builder, and schema manager, each independently configurable via YAML / Injector
Creation of new DBQueryGenerator for database specific generation of SQL
Support for parameterised queries, move of code base to use these over escaped conditions
Refactor of SQLQuery into separate query classes for each of INSERT UPDATE DELETE and SELECT
Support for PDO
Installation process upgraded to use new ORM
SS_DatabaseException created to handle database errors, maintaining details of raw sql and parameter details for user code designed interested in that data.
Renamed DB static methods to conform correctly to naming conventions (e.g. DB::getConn -> DB::get_conn)
3.2 upgrade docs
Performance Optimisation and simplification of code to use more concise API
API Ability for database adapters to register extensions to ConfigureFromEnv.php
Move functionality from static start and destroy functions into instance
methods, allowing these to be overloaded. This works the same way as
calling Session::set() which then in turn calls inst_set()
Additionally use Injector to create the default Session instance to
allow the class to be swapped out.
BUG Disabled disruptive test case in DirectorTest
API RequestProcessor and VersionedRequestFilter now both correctly implement RequestFilter
Better PHPDoc on RequestFilter and implementations
BUG Resolve issue with DirectorTest breaking RequestProcessor
Injector::nest and Injector::unnest are introduced to better support sandboxing of testings.
Injector and Config ::nest and ::unnest support chaining
Test cases for both Injector::nest and Config::nest
Previously we were using the request to get the action parameter. However for custom URL structures and nested controllers, this won't work and causes template selection to break.
SS_HTTPRequest can be read like an array, e.g. echo $request['a'], but cannot be written like an array, e.g. $request['a'] = 5; Added comment to caution people.
See line 375:
==================================================================
/**
* @ignore
*/
public function offsetSet($offset, $value) {}
/**
* @ignore
*/
public function offsetUnset($offset) {}
==================================================================
Might be good to write something about how you are supposed to modify a request, or what you are supposed to do instead (a redirect?).
Anchors should never make it to the server when they are in the browser URL bar, however tests are slightly different and some `Link()` functions may return a URL anchor. Instead of every test checking a link and stripping the anchor, I feel the Director::test() function should strip them off.
Director::test() don't set the HTTP_HOST with the port number if that has been set.
Later call to Director::makeRelative() will return wrong value because of the strict string matching
(http://localhost/ != http://localhost:8000)
This bug affects all modules that are using Director::test in CLI where the $_FILE_TO_URL_MAPPING
have been set to use a domain with a port in it, i.e. static publishers.
A service factory can be used for creating instances where a non-trivial
construction process is required. This is done by adding a `factory`
key to the service definition.
De-facto standard for identifying the originating protocol of an HTTP request through a reverse proxy or load balancer.
http://www.geekisp.com/faq/6_65_en.html
