* 2.0:
replaced magic strings by proper constants
refactored tests for Request
fixed the logic in Request::isSecure() (if the information comes from a source that we trust, don't check other ones)
added a way to configure the X-Forwarded-XXX header names and a way to disable trusting them
fixed algorithm used to determine the trusted client IP
removed the non-standard Client-IP HTTP header
Conflicts:
src/Symfony/Component/HttpFoundation/Request.php
src/Symfony/Component/HttpFoundation/Tests/RequestTest.php
Calling setDefaultLocale was replacing the intl locale even if the locale
was already set in the Request, thus leading to a different value than the
request locale.
Changed checking CONTENT_TYPE from server to headers variable
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #5697
Todo: -
License of the code: MIT
* 2.0:
fixed CS
added doc comments
[HttpKernel][Translator] Fixed type-hints
[Translation] forced the catalogue to be regenerated when a resource is added (closes symfony/Translation#1)
[HttpFoundation] Fixed#5611 - Request::splitHttpAcceptHeader incorrect result order.
Conflicts:
src/Symfony/Component/Process/Process.php
tests/Symfony/Tests/Component/HttpFoundation/RequestTest.php
Quoted from the ticket it solves for future reference:
"I've been having issues with using htdigest auth (requirement for me to
work with) after upgrading to 2.1. Each time a resource is loaded, a
prompt is given for the HTTP Auth username and password, and Chrome does
not automatically respond to these 401 responses with the credentials it
already has. I've traced the issue to being caused by the HttpFoundation
Component, specifically Request.php.
The request class adds the PHP_AUTH_USER/PHP_AUTH_PW parameters to the
request URI (changes http://www.mysite.com requests to
http://user:pw@www.mysite.com) in getSchemeAndHttpHost(). This behaviour
is not specified in the HTTP RFC, and is incompatible with Chrome as of
Chrome 19, IE (as of IE 9) and has special behaviour in Firefox (prompts
the user to confirm they know they're logging into the site, which is an
ambiguous behaviour at best, but at least it's something if they're
going to support it for now).
This functionality was added about to HttpFoundation about a year ago,
but it really should be removed and standard protocol practices should
be followed. This practice makes it possible for cross-site tracking and
other malicious behaviours to be performed by hiding information in the
authorization headers, which explains why most browsers no longer
support or take exception with it.
The offending line is specifically this. Replacing it with return
$this->getScheme().'://'.$this->getHttpHost(); seems to solve the
problem."
Commits
-------
c40a4e5 [HttpFoundation] fix query string normalization
f9ec2ea refactored test method
0880174 [HttpFoundation] added failing tests for query string normalization
Discussion
----------
[HttpFoundation] fix query string normalization
This fixes the query string normalization. There were several problems in it (see test cases that I added).
The main issue, that first catched my eye, was that the query string was urldecoded before it was exploded by `=`. See old code: `explode('=', rawurldecode($segment), 2);`. This means an encoded `=` (`%3D`) would falsely be considered a separator and thus lead to complete different parameters. The fixed test case is at `pa%3Dram=foo%26bar%3Dbaz&test=test`.
---------------------------------------------------------------------------
by Tobion at 2012-07-04T02:21:25Z
cc @simensen considering your PR 4711
Commits
-------
d37003e [HttpFoundation] small fixes in Request
Discussion
----------
[HttpFoundation] small fixes in Request
phpdoc fixes,
making http_build_query explicit
fixing query string of '0', that was ignored.
Unfortunately this '0' problematic is omnipresent because PHP makes it so easy to get wrong (as it is converted to boolean false). I don't know how often I fixed such issue already.
Commits
-------
f72ba0a Fixed detection of an active session
Discussion
----------
[WIP][HttpFoundation][Session] Fixed detection of an active session
Bug fix: yes
Feature addition: no
Backwards compatibility break: not sure
Symfony2 tests pass: no
Fixes the following tickets: #4529
Todo: Fix failing tests
License of the code: MIT
Documentation PR: ~
This fixes the problem when the session variable inside $request now has always data in it as it's now more powerful but this introduces the problem that the old way of detecting if a session is started or not doesn't work anymore.
---------------------------------------------------------------------------
by travisbot at 2012-06-09T21:53:17Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1578839) (merged 9ae13e12 into 6266b72d).
---------------------------------------------------------------------------
by drak at 2012-06-10T01:57:59Z
Sessions should be started implicitly. The SF auto_start config parameter controls the session listener to start the session.
---------------------------------------------------------------------------
by dlsniper at 2012-06-11T06:46:02Z
So this patch is correct then and I should continue the work on it?
---------------------------------------------------------------------------
by drak at 2012-06-11T07:51:39Z
@dlsniper - no it's not correct. The session should not be auto-started like this, @fabpot and I recently discussed it.
---------------------------------------------------------------------------
by dlsniper at 2012-06-11T07:52:55Z
@Drak, ok I'll remove the patch for auto_start then but the fix for start would still stand, right?
---------------------------------------------------------------------------
by drak at 2012-06-12T18:40:35Z
@dlsniper - I have no objection to the rest of the PR except for the autostart stuff. I've annotated for clarity :)
---------------------------------------------------------------------------
by travisbot at 2012-06-12T19:51:12Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1604158) (merged 3499980e into 37550d23).
---------------------------------------------------------------------------
by travisbot at 2012-06-12T19:52:00Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1604166) (merged dcc73071 into 37550d23).
---------------------------------------------------------------------------
by dlsniper at 2012-06-12T19:56:51Z
Seems Travis doesn't like the squashing of commits that I've did but the PR does pass the normal tests.
@drak is this good for merging now?
Thanks :)
---------------------------------------------------------------------------
by dlsniper at 2012-06-13T09:05:09Z
@fabpot this can be merged safely, I've just applied the patch on my production application and the patch is ok, it's just travis failing.
Thanks
---------------------------------------------------------------------------
by travisbot at 2012-06-13T09:23:46Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1608735) (merged 1a6eabd2 into 37550d23).
---------------------------------------------------------------------------
by travisbot at 2012-06-13T09:28:26Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1608758) (merged 4e3a93c8 into 37550d23).
---------------------------------------------------------------------------
by dlsniper at 2012-06-13T09:29:28Z
I've noticed that this is failing, I'll fix it later on today.
---------------------------------------------------------------------------
by travisbot at 2012-06-13T15:14:01Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1611541) (merged 5504c4b7 into 37550d23).
---------------------------------------------------------------------------
by drak at 2012-06-13T15:23:47Z
It's possible that other tests are failing not related to this PR. Run the tests on the current master, and try rebasing your branch to the current master also.
---------------------------------------------------------------------------
by dlsniper at 2012-06-13T15:44:22Z
I've just reminded why this is failing on builds, I can't do them locally because of this:
```
Installing dev dependencies
Your requirements could not be solved to an installable set of packages.
Problems:
- Problem caused by:
- Installation request for doctrine/orm [>= 2.2.0.0, < 2.4.0.0-dev]: Satisfiable by [doctrine/orm-2.2.2, doctrine/orm-2.2.1, doctrine/orm-2.2.0, doctrine/orm-2.2.x-dev, doctrine/orm-2.3.x-dev].
```
I'll try and install this somehow and see what's wrong with it.
---------------------------------------------------------------------------
by mvrhov at 2012-06-13T18:08:58Z
@dlsniper: as @stof said to me this should be resolved in latest versions of composer, but it seems that is not. The problem is that composer cannot figure out that you are on dev-master if you try to instal dev. dependencies on feature branch. Take a look at the .travis.yml file on how to do a proper dev vendors install.
cc @Seldaek
---------------------------------------------------------------------------
by dlsniper at 2012-06-13T23:08:53Z
@mvrhov Thanks for pointing this out.
@drak I still got two tests not passing but I'm not sure how to fix them as adding $session->start() will either fail with the message that the session has already been started, the headers_sent() call which returns true. Any help with them will be greatly appreciated. Thanks!
Here is what the HttpKernel tests are returning:
```
There were 2 failures:
1) Symfony\Component\HttpKernel\Tests\EventListener\LocaleListenerTest::testDefaultLocaleWithSession
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'es'
+'fr'
/var/www/symfony-orig/src/Symfony/Component/HttpKernel/Tests/EventListener/LocaleListenerTest.php:51
2) Symfony\Component\HttpKernel\Tests\EventListener\LocaleListenerTest::testLocaleFromRequestAttribute
Expectation failed for method name is equal to <string:set> when invoked 1 time(s).
Method was expected to be called 1 times, actually called 0 times.
FAILURES!
Tests: 263, Assertions: 1025, Failures: 2, Skipped: 10.
```
---------------------------------------------------------------------------
by travisbot at 2012-06-13T23:42:59Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1614883) (merged 1004b7c0 into c07e9163).
---------------------------------------------------------------------------
by travisbot at 2012-06-13T23:53:06Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1614897) (merged f72ba0a2 into c07e9163).
---------------------------------------------------------------------------
by dlsniper at 2012-06-16T20:14:41Z
@stof / @vicb Hi, do either of you think that you can either point me out to the right direction for fixing this either ping someone else for home help as @drak doesn't seem available for this and at the moment I'm pretty much clueless in what direction I should take this fix.
Thanks!
---------------------------------------------------------------------------
by dlsniper at 2012-06-19T14:16:29Z
ping @fabpot Can you please provide some input on this one as I'm a bit stuck and seems noone else is available.
---------------------------------------------------------------------------
by drak at 2012-06-20T10:24:43Z
fyi - I'll be able to look again in a few days
---------------------------------------------------------------------------
by fabpot at 2012-07-01T07:53:28Z
I'm +1 to add the `isStarted()` method, but -1 for the change of `Request::hasSession`.
---------------------------------------------------------------------------
by drak at 2012-07-01T09:06:15Z
@fabpot, I agree. `hasSession()` should not be changed, it's semantically incorrect to make it return effectively "hasActiveSession".
Commits
-------
df8d94e added Request::getSchemeAndHttpHost() and Request::getUserInfo() (closes#4312, refs #3416, refs #3056)
Discussion
----------
added Request::getSchemeAndHttpHost() and Request::getUserInfo()
see #4312
---------------------------------------------------------------------------
by travisbot at 2012-06-28T15:22:03Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1730172) (merged 598bd56f into 0d275701).
---------------------------------------------------------------------------
by Seldaek at 2012-06-28T15:22:35Z
Why not just `getSchemeAndHost`? That sounds long enough, and is fairly explicit given the context.
---------------------------------------------------------------------------
by fabpot at 2012-06-28T15:25:34Z
@Seldaek because (and that's probably unfortunate) we have both `getHost()` and `getHttpHost()`. The former does not include the port whereas the latter does.
---------------------------------------------------------------------------
by Seldaek at 2012-06-28T15:26:42Z
Ok makes sense.
---------------------------------------------------------------------------
by travisbot at 2012-06-28T16:11:16Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1730630) (merged df8d94e3 into 884a8264).
Commits
-------
b217897 [HttpFoundation] Complete Request::overrideGlobals
Discussion
----------
[2.2][HttpFoundation] complete Request::overrideGlobals
Bug fix: yes
Feature addition: yes
Backwards compatibility break: yes
Symfony2 tests pass: [](http://travis-ci.org/stealth35/symfony)Fixes the following tickets: -
Todo: -
---------------------------------------------------------------------------
by stealth35 at 2011-12-15T14:20:36Z
Thank guys, should be better now
---------------------------------------------------------------------------
by stealth35 at 2011-12-15T16:14:40Z
@stloyd ✌️
---------------------------------------------------------------------------
by stloyd at 2011-12-15T16:22:48Z
@stealth35 You should update also [`RequestTest`](https://github.com/symfony/symfony/blob/master/tests/Symfony/Tests/Component/HttpFoundation/RequestTest.php#L623) which would show you typos you have few mins ago ;-)
---------------------------------------------------------------------------
by stealth35 at 2011-12-15T16:57:16Z
@stloyd done, thanks for your review
---------------------------------------------------------------------------
by canni at 2011-12-15T20:27:28Z
As this is bugfix, this shouldn't be re-based against 2.0?
---------------------------------------------------------------------------
by stealth35 at 2011-12-15T20:50:05Z
@canni It's more a forget feature, I tagged it to bug fix because of the `FIXME`, and it's add a method, IMO there is no rush
---------------------------------------------------------------------------
by canni at 2011-12-15T20:55:28Z
@stealth35 no rush at all, I was just curious :)
---------------------------------------------------------------------------
by vicb at 2012-01-06T16:24:31Z
I would say "Backwards compatibility break: yes" i.e.tests have been modified.
---------------------------------------------------------------------------
by stealth35 at 2012-01-06T16:36:15Z
@vicb the tests are not modified, just some addition
---------------------------------------------------------------------------
by vicb at 2012-01-06T16:40:30Z
@stealth35 https://github.com/symfony/symfony/pull/2892/files#L2R46
---------------------------------------------------------------------------
by stealth35 at 2012-01-06T17:13:07Z
@vicb it's not a compatibility break ...
---------------------------------------------------------------------------
by vicb at 2012-01-06T17:19:35Z
Well, same inputs, different outputs, this is a compatibility break to me.
But however it is named we should not change the behavior of this class; Client values are values as passed by the client you should no try to guess them.
---------------------------------------------------------------------------
by stealth35 at 2012-01-06T17:32:41Z
@vicb the behavior ? when you change the GET or POST values with `HttpFoundation\*Bag` (replace/set) it's the same thing
---------------------------------------------------------------------------
by vicb at 2012-01-06T17:35:39Z
I am referring to the difference in behavior between the current implementation and the version in this PR.
They do not behave the same and that's why the tests have been modified.
---------------------------------------------------------------------------
by fabpot at 2012-02-14T23:33:42Z
any progress on this PR?
---------------------------------------------------------------------------
by vicb at 2012-02-15T07:48:34Z
To make it clear I strongly disagree with the modifs in this PR. Available to help if needed.
---------------------------------------------------------------------------
by stealth35 at 2012-02-15T09:24:50Z
@fabpot Well, `move_uploaded_file` will not work so I have some doubt about this, @vicb just don't like the fact to add the mime type type and the size, it's not an important thing, I can remove it we can discuss later about that,
@vicb the last thing to do, it's to recreate the weird php $_FILES array
---------------------------------------------------------------------------
by vicb at 2012-02-23T17:11:29Z
@stealth35 I don't think we can bypass the `move_uploaded_file` security check - which is good. Is there any interest in this PR w/o this ?
If no we should just update phpDoc comment and remove the FIXME (meaning we can not override the `$_FILES`).
---------------------------------------------------------------------------
by stealth35 at 2012-03-10T16:13:14Z
@vicb updated
---------------------------------------------------------------------------
by vicb at 2012-03-11T09:38:20Z
@stealth35 what about adding some unit tests ?
---------------------------------------------------------------------------
by stealth35 at 2012-03-11T11:06:44Z
> what about adding some unit tests ?
@vicb `request_order` is PHP_INI_PERDIR, so I don't really how to handle this
---------------------------------------------------------------------------
by vicb at 2012-03-11T11:15:55Z
by creating a `protected getRequestOrder()` method or something like this ?
---------------------------------------------------------------------------
by stealth35 at 2012-03-11T11:36:11Z
it's too bad to create a method just for this, I can make cond in the test
``` php
<?php
$request->initialize(array('get' => 'foo'), array('post' => 'bar'));
$request->overrideGlobals();
$request_order = ini_get('request_order');
if ('gp' === $request_order) {
$this->assertEquals(array('get' => 'foo', 'post' => 'bar'), $_REQUEST);
} else if ('pg' === $request_order) {
$this->assertEquals(array('post' => 'bar', 'get' => 'foo'), $_REQUEST);
}
// ...
```
---------------------------------------------------------------------------
by vicb at 2012-03-11T12:02:17Z
This would only test one case.
Some thoughts about your snippet:
* The init should probably be `$request->initialize(array('foo' => 'get'), array('foo' => 'post'));`,
* `$request_order` does not take into account `variables_order.ini`,
* missing `strtolower`
---------------------------------------------------------------------------
by fabpot at 2012-03-23T21:21:59Z
What's the status of this PR? What needs to be done before merging?
---------------------------------------------------------------------------
by stealth35 at 2012-03-24T18:33:42Z
@fabpot missing some tests, it's not essay to tests an `ini`directive, @vicb recommand a `getRequestOrder` method, it's not a bad idea
---------------------------------------------------------------------------
by vicb at 2012-03-24T20:06:53Z
and change `$request_order` to `$requestOrder` as suggested by @henrikbjorn I can't find where
---------------------------------------------------------------------------
by stealth35 at 2012-06-14T12:42:25Z
I need help for testing
``` php
<?php
$request = $this->getMock('Request', array('overrideGlobals', 'initialize'));
$request->expects($this->any())
->method('getRequestOrder')
->will($this->returnValue('gp'));
$request->initialize(array('foo' => 'fooget'), array('foo' => 'foopost'));
$request->overrideGlobals();
$this->assertEquals(array_merge($_GET, $_POST), $_REQUEST);
```
