This partially reverts cec890c. In addition to other cleanup the commit changed
from using $_SERVER to getenv. As @kafene said on issue #21, getenv provides a
nicer API making the code clean. I.E.
$val = getenv('val') ?: 'default';
Instead of:
$val = isset($_SERVER['val']) ? $_SERVER['val'] : 'default';
Although this is true unfortuantly it is less reliable. Using getenv in this
way assumes the application is running under some sort of CGI interface or
an interface that is simulating the CGI interface.
While this assumption is very often true it is not always true. For example
when using [PHP built-in webserver][1] (useful for development) getenv will
return false for most of these values even through $_SERVER is populated. I
believe also some interfaces on Windows don't populate getenv.
This means that flight is not usable in those environments. By partially
reverting cec890c we re-enable flight in those environments.
For Engine.php and Response.php I just directly reverted cec890c. Since request
makes so much use of getenv it seemed wise to abstract the conditional checking
to keep the code clean via a private function.
The tests were also updated to populate $_SERVER instead of the environment
via putenv.
[1]: http://php.net/manual/en/features.commandline.webserver.php
Core functionality has been moved to a namespaced Engine class. The
existing Flight class is now just a static pass-through to the Engine class.
Also fixed autoloading and initialization issues.
See: http://php.net/manual/en/function.header.php
2nd option, $replace, should be false if sending multiple headers with the same name.
The difference can be observed by editing index.php (the example index page) so that before `echo 'hello'` is a line: `flight::response()->cache(false);`
and editing Response.php so that before `exit($this->body)` is a line: `var_dump(headers_list());`
Before change:
`array (size=3)`
`0 => string 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' (length=38)`
`1 => string 'Cache-Control: max-age=0' (length=24)`
`2 => string 'Pragma: no-cache' (length=16)`
After:
`array (size=5)`
`0 => string 'Expires: Mon, 26 Jul 1997 05:00:00 GMT' (length=38)`
`1 => string 'Cache-Control: no-store, no-cache, must-revalidate' (length=50)`
`2 => string 'Cache-Control: post-check=0, pre-check=0' (length=40)`
`3 => string 'Cache-Control: max-age=0' (length=24)`
`4 => string 'Pragma: no-cache' (length=16)`
- added "secure" parameter to avoid boilerplate "if https && https != 'off'"
- added "accept" parameter containing request's HTTP_ACCEPT value if any
- Changed IP to always be REMOTE_ADDR, as this is the only "real" ip of the request.
- Added 'proxy' parameter containing any proxy-forwarded IP
- Changed getIpAddress to getProxyIpAddress
- renamed $vars to $forwarded to be a bit more explicit
- Removed REMOTE_ADDR from proxy forwarded addresses to detect
- change explode() to sscanf, will explain this later.
- added flags to the filter_var, will also explain later
- added getMethodOverride function to detect request method overrides
I did some research because I was wondering why it would be necessary to check
for a comma, and apparently some proxies do send a comma separated list of IP
addresses, with the originating client IP as the first one. It had a feeling
that instead of using explode() where the first value would always be returned,
there must be another way to get the first value of a token-delimited string,
or just the whole string if there was no token, and I bumped in to my old
friend sscanf. So the loop is now 3 levels.
As far as the flags, see: http://php.net/manual/en/filter.filters.flags.php
These ensure that any IP detected is not a useless IP behind a remote NAT.
For example, a corporate proxy might send HTTP_X_FORWARDED_FOR using the
internal IP of the user, but the only useful IP in this case is that of
the proxy, which PHP gets as REMOTE_ADDR.
If you find any of these changes acceptable but don't want to merge them
all, do feel free to implement whichever you like.
I was thinking of adding a getRequestMethod() function to check for
`$_SERVER['HTTP_X_HTTP_METHOD_OVERRIDE']` or `$_POST['_method']`
to allow clients to negotiate PUT/DELETE requests,
but personally I am indifferent to these, as I never use
methods beyond GET and POST (I'm not very RESTful I guess),
and it's not really my place to be writing an implementation
of either. Other frameworks seem to just overwrite the method
parameter so that it appears to be the overridden one.
Mike Cao