* 2.0: added trusted hosts check Conflicts: src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php src/Symfony/Bundle/FrameworkBundle/Tests/DependencyInjection/ConfigurationTest.php src/Symfony/Component/HttpFoundation/Tests/RequestTest.php
… another one like foo:bar:baz (closes #8245)
This PR was merged into the 2.1 branch. Discussion ---------- [Form] [Validator] Fixed post_max_size = 0 bug (issue #8065) | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #8065 | License | MIT | Doc PR | Commits ------- 2038329 [Form] [Validator] Fixed post_max_size = 0 bug (Issue #8065)
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.