This PR was merged into the 2.2 branch.
Discussion
----------
[WebProfilerBundle] force the Content-Type to html in the web profiler controllers
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | [](https://travis-ci.org/lsmith77/symfony)
| Fixed tickets | -
| License | MIT
| Doc PR | -
This just forces the Content-Type to match what will be returned, otherwise if the request format happens to be something else than HTML (which can be the case when building an app that only does JSON/XML with FOSRestBundle) it can happen that the Response class automatically sets a different Content-Type.
The approach taken here matches https://github.com/nelmio/NelmioApiDocBundle/blob/master/Controller/ApiDocController.php#L24
Commits
-------
6d2135b force the Content-Type to html in the web profiler controllers
There are cases where $env or $_ENV can contain a value that is an array
This will cause Process to throw an Array to String conversion exception
Initially I submitted a patch of Process.php, however Fabien indicated
that it shouldn't be fixed there (see below pull request).
Before recently, a simple work around would be in php.ini to set:
register_argc_argv = On
However with recent changes, this seems to no longer work.
Original pull request: https://github.com/symfony/symfony/pull/7354
See ticket https://github.com/symfony/symfony/issues/7196
This PR was merged into the 2.2 branch.
Discussion
----------
[Finder] Fix SplFileInfo::getContents isn't working with ssh2 protocol
| Q | A
| -------------:| ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #8219
| License | MIT
Commits
-------
849f3ed [Finder] Fix SplFileInfo::getContents isn't working with ssh2 protocol
* 2.1:
Revert "[Console] ensure exit code between 0-254"
[Console] ensure exit code between 0-254
[Console] fix status code when Exception::getCode returns something like 0.1
Fixed exit code for exceptions with error code 0
* 2.1:
Fix several instances of doubled words
[Finder] Fix iteration fails with non-rewindable streams
[Finder] Fix unexpected duplicate sub path related AppendIterator issue
Added type of return value in VoterInterface.
Fixed two bugs in HttpCache
Conflicts:
src/Symfony/Component/Finder/Tests/FinderTest.php
This PR was squashed before being merged into the 2.1 branch (closes
Discussion
----------
[Finder] Fix iteration fails with non-rewindable streams
<table>
<tr>
<th>Q</th><th>A</th>
</tr>
<tr>
<td>Bug fix?</td><td>yes</td>
</tr>
<tr>
<td>New feature?</td><td>no</td>
</tr>
<tr>
<td>BC breaks?</td><td>no</td>
</tr>
<tr>
<td>Deprecations?</td><td>no</td>
</tr>
<tr>
<td>Tests pass?</td><td>yes</td>
</tr>
<tr>
<td>Fixed tickets</td><td>#3585, #7834</td>
</tr>
<tr>
<td>License?</td><td>MIT</td>
</tr>
</table>
- [x] Add a good detection of non seekable stream
- [x] Add some unit tests
But the iteration under ftp stream still not work properly. Edit: need
tests for that.
Commits
-------
169c0b9 [Finder] Fix iteration fails with non-rewindable streams
1. 304 responses always send "Content-Type: text/html; charset=UTF-8"
header
I discovered that the HttpCache::handle method calls Response::prepare
after calling Response::isModified. Response::isModified removes the
Content-Type header as it should, but Response::handle adds in the
default Content-Type header when none is set. If the default
Content-Type is not the correct Content-Type, then the Content-Type in
the cache gets clobered. I solved this problem by moving the
Response::isModified call after the Response::prepare call. I updated
the testRespondsWith304WhenIfModifiedSinceMatchesLastModified and
testRespondsWith304WhenIfNoneMatchMatchesETag tests to verify that the
Content-Type header was not being sent for 304 responses.
2. Failure to invalidate cached entities referred to by the Location
header
I discovered that the Store::invalidate method was looking for Location
and Content-Location headers to invalidate, but it was looking in the
request headers instead of the response headers. Because the
Store::invalidate method doesn't take a response, I decided it was
better to move this logic to the HttpCache::invalidate method instead.
I updated the testInvalidatesCachedResponsesOnPost test to verify that
Location headers are getting invalidated correctly.
This PR was merged into the 2.1 branch.
Discussion
----------
[Console] fix and refactor exit code handling
Split of #8038
Commits
-------
5c317b7 [Console] fix and refactor exit code handling
* 2.1:
Fixed XML syntax.
Fixed parsing of leading blank lines in folded scalars. Closes#7989.
Added a test case for Loader::import().
Fixed Loader import
[Console] Added dedicated testcase for HelperSet class
