This PR was squashed before being merged into the 2.3 branch (closes#15249).
Discussion
----------
[HttpFoundation] [PSR-7] Allow to use resources as content body and to return resources from string content
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | not yet
* Allows to fix tests of https://github.com/symfony/psr-http-message-bridge with PHP 5.6.
* Ease the transition to PSR-7 (in PSR-7, almost everything is stream - #15186)
Maybe should I open it against 2.8 but it can be considered a bug fix at least for the part "returning a string as a resource".
Commits
-------
059964d [HttpFoundation] [PSR-7] Allow to use resources as content body and to return resources from string content
In PHP7 the behaviour of substr() changed.
To resume: "Truncating an entire string should result in a string."
See: https://bugs.php.net/bug.php?id=62922
This PR was squashed before being merged into the 2.3 branch (closes#14335).
Discussion
----------
[HttpFoundation] Fix baseUrl when script filename is contained in pathInfo
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #13617
| License | MIT
| Doc PR |
When the script filename is just /index.php, dirname() returns '/' for it. In Request::prepareBaseUrl() we append '/' to it (as introduced in #13039), which is wrong in this scenario as the resulting string is '//'.
When we rtrim('/') the output of dirname() then '/' would be constructed in this case, and in all other cases it makes no difference as dirname() already trims the right forward slash if there are path segments.
The test-cases should clarify the exact scenario.
Commits
-------
f24a6dd [HttpFoundation] Fix baseUrl when script filename is contained in pathInfo
This PR was merged into the 2.3 branch.
Discussion
----------
CS: Pre incrementation/decrementation should be used if possible
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
Fixes provided by new fixer: https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/1113
If this pr is merged I would change the level of the fixer to `symfony`.
Commits
-------
c5123d6 CS: Pre incrementation/decrementation should be used if possible
Reduce couple count calls in [Yaml]
Modernize type casting, fix several strict comparisons
Unsets merged
Elvis operator usage
Short syntax for applied operations
This PR was squashed before being merged into the 2.3 branch (closes#13039).
Discussion
----------
[HttpFoundation] [Request] fix baseUrl parsing to fix wrong path_info
Hi everyone!
We at trivago had an issue with the Request object. It seems that all versions of symfony 2.x and 3.x are affected from this (possible) bug (don't checked 1.x).
Here is the problem:
some old legacy pages are deployed in the Document Root, let's say /var/www/www.test.com/ .
one or more new applications based on symfony are deployed to /var/release/new_app1/ , /var/release/new_app2/ , ... .
in /var/www/www.test.com/ there is a symlink "app" to /var/release/new_app1/web, like:
/var/www/www.test.com/app --> /var/release/new_app1/web/
there is a "SEO"/human-readable rewrite rule for Document Root (if called path/file not exist): (.*) --> app/app.php
the problem comes, when the user calls a uri starting with "app" or whatever the rewrite rule / symlink points to:
the user calls "http://www.test.com/apparthotel-1234"
results in $_SERVER parameters like this
```
'DOCUMENT_ROOT' =>'/var/www/www.test.com',
'SCRIPT_FILENAME' => '/var/www/www.test.com/app/app.php',
'SCRIPT_NAME' => '/app/app.php',
'PHP_SELF' => '/app/app.php/apparthotel-1234'
```
in Request::prepareBaseUrl() there are checks to find the baseUrl:
```
if ($baseUrl && false !== $prefix = $this->getUrlencodedPrefix($requestUri, $baseUrl)) {
// full $baseUrl matches
return $prefix;
}
if ($baseUrl && false !== $prefix = $this->getUrlencodedPrefix($requestUri, dirname($baseUrl))) {
// directory portion of $baseUrl matches
return rtrim($prefix, '/');
}
```
first it is checked if (in our case) "/app/app.php" is in the request uri (/apparthotel-1234).
it's not.
then it takes the dirname (of /app/app.php) which is /app and checks if it is in the request uri (/apparthotel-1234), and YES, it is! and "/app" is returned, but this is wrong, it should be empty (because it comes from a rewrite rule from root: /)!
later in preparePathInfo(), if there is a baseUrl, then the baseUrl is removed from the request uri:
/apparthotel-1234 ---> /arthotel-1234
The cause is, the second baseUrl check, checks if the path of the application is already in the uri, like when the request was "http://www.test.com/app/apparthotel-1234" and hit a rewrite rule like (.*) --> app.php in there, but because it matches a directory it must match "dirname($baseUrl) . '/'".
I also needed to fix one unit test of the getBaseUrl test:
the request uri recently was "/foo%20bar".
but from the $_SERVER infos "foo bar" is a directory, see:
```
'SCRIPT_FILENAME' => '/home/John Doe/public_html/foo bar/app.php',
'SCRIPT_NAME' => '/foo bar/app.php',
'PHP_SELF' => '/foo bar/app.php',
```
webservers will redirect a request "http://www.test.com/foo%20bar" to "http://www.test.com/foo%20bar/" when "foo bar" is a directory. checked this for apache 2.x and nginx 1.4.x.
this fix is for symfony master (3.0.x, see #13039).
I also prepared a merge request for actual 2.7 branch, it will also follow in some minutes. (see #13040)
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | this, #13040, #13038, #7329
| License | MIT
[HttpFoundation] [Request]
* added missing slash to baseUrl-path part check to remove the path, only when it's also a path in the uri
[HttpFoundation] [Tests] [RequestTest]
* fixed and added unittests
This is the symfony 2.3 branch fix for the issue related to #13038 and #13040
Happy christmas!
Commits
-------
3a3ecd3 [HttpFoundation] [Request] fix baseUrl parsing to fix wrong path_info
This PR was merged into the 2.3 branch.
Discussion
----------
[HttpFoundation] CSRF warning docs on Request::enableHttpMethodParameterOverride()
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #12043
| License | MIT
| Doc PR | /
Since I wanted to understand this issue I did some research and altered the comment block. Is this a clear enough explanation or does it need more?
Commits
-------
deb70ab CSRF warning docs on Request::enableHttpMethodParameterOverride()
[HttpFoundation] fixed the docs so that it gives some explanation about how you are vulnerable to CSRF when you enable the httpMethodeParameterOverride
This PR was merged into the 2.3 branch.
Discussion
----------
n/a
n/a
Commits
-------
9e1bc22 Add tests and more assertions
101a3b7 [FrameworkBundle][Translator] Validate locales.
This PR was merged into the 2.3 branch.
Discussion
----------
n/a
n/a
Commits
-------
1ee96a8 Test examples from Drupal SA-CORE-2014-003
5506ee8 Fix potential DoS when parsing HOST
See [PSR-2](http://www.php-fig.org/psr/psr-2/) paragraph 5.2
> There MUST be a comment such as `// no break` when fall-through is intentional in a non-empty case body.
Related to #11181
Request#getUser() and Request#getPassword() introduced in
aecfd0a891 do not handle the lack of
PHP_AUTH_USER and PHP_AUTH_PW in $this->server when using PHP-FPM. Use
$this->headers instead.
Furthermore, the test of empty password now expects an empty string
instead of NULL according to a450d002f2.
This PR was merged into the 2.3 branch.
Discussion
----------
unified return null usages
| Q | A
| ------------- | ---
| License | MIT
This PR unifies the way we return `null` from a function or method:
* always use `return;` instead of `return null;` (the current code base uses both);
* never use `return;` at the end of a function/method.
Commits
-------
d1d569b unified return null usages
