* 2.1:
added support for the X-Forwarded-For header (closes#6982, closes#7000)
fixed the IP address in HttpCache when calling the backend
[EventDispatcher] Added assertion.
[EventDispathcer] Fix removeListener
[DependencyInjection] Add clone for resources which were introduced in 2.1
[DependencyInjection] Allow frozen containers to be dumped to graphviz
Fix 'undefined index' error, when entering scope recursively
[Security] fixed session creation on login (closes#7011)
Add dot character `.` to legal mime subtype regular expression
[HttpFoundation] fixed the creation of sub-requests under some circumstancies (closes#6923, closes#6936)
This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes#6393).
Commits
-------
697d53d [Router] Fixed XmlFileLoaderTest::testLoadThrowsExceptionWithInvalidFileEvenWithoutSchemaValidation
Discussion
----------
[Router] Fixed test
This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes#6708).
Commits
-------
90a3e7a [HttpFoundation] moved file hash calculation to own method
Discussion
----------
[HttpFoundation] moved file hash calculation to own method
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Todo: -
Fixes the following tickets: #6101
License of the code: MIT
Documentation PR: -
This commit adds ability to change default hashing implementation by extending BinaryFileResponse.
---------------------------------------------------------------------------
by stloyd at 2013-01-11T16:23:30Z
IMO it's looks a like overkill...
---------------------------------------------------------------------------
by lsmith77 at 2013-01-11T16:39:33Z
hmm yeah .. seems like something that could be done via inheritance ..
---------------------------------------------------------------------------
by Tobion at 2013-01-11T17:44:29Z
I agree, overriting the method is much simpler solution.
---------------------------------------------------------------------------
by jalliot at 2013-01-11T18:16:04Z
Besides the `$autoetag` variable is false by default so you have to explicitly enable this behavior...
---------------------------------------------------------------------------
by povilas at 2013-01-11T18:39:31Z
@lsmith77, @Tobion, you mean, just move hash calculation to separate protected method, and when you want to change hashing you must extend BinaryFileResponse?
This PR was squashed before being merged into the 2.2 branch (closes#6972).
Commits
-------
4cbdbcb [Validator] Add check for existing metadata on property
Discussion
----------
[Validator] Add check for existing metadata on property
| Q | A
| ------------- | ---
| Bug fix? | no (sort of)
| New feature? | no
| BC breaks? | no (I don't think so)
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
Todo:
- [x] Check if the new method should be added to the interface as well.
This adds a check for metadata existence before usage else the code will emit a warning.
This should not be a BC break or a bug fix as the patched code is 2.2 specific.
@bschussek let me know if I should add the method in the interface as well. Thank you.
---------------------------------------------------------------------------
by vicb at 2013-02-05T10:40:56Z
Strictly speaking this is a BC break (you are adding a public method). But I guess we should better defined what should be describe as BC break - I have asked myself the same question more than one time /cc @fabpot
Please also add a UT and a note in the changelog.
---------------------------------------------------------------------------
by dlsniper at 2013-02-05T11:26:30Z
@vicb thanks for input. In this case I guess I should add the method to the interface as well.
As for unit tests I'll add them soon as well.
---------------------------------------------------------------------------
by fabpot at 2013-02-05T14:19:14Z
Can you add a test?
---------------------------------------------------------------------------
by dlsniper at 2013-02-05T15:57:12Z
I'll do it tonight as I've bumped into some work related issues.
---------------------------------------------------------------------------
by fabpot at 2013-02-11T11:11:12Z
Just for the record, this is not a BC break as the interface was added in 2.2.
This PR was merged into the 2.0 branch.
Commits
-------
4ce9ac3 [EventDispatcher] Added assertion.
Discussion
----------
[EventDispatcher] Added assertion
re #7023, I think it actually makes sense to add an assertion here. It reveals the intent of the test (listener is not removed).
---------------------------------------------------------------------------
by vicb at 2013-02-10T11:32:06Z
I don't think the assertion would fail with the former code, would it ?
---------------------------------------------------------------------------
by vicb at 2013-02-10T11:34:30Z
I mean an error would be generated even before the assertion.
---------------------------------------------------------------------------
by jakzal at 2013-02-10T11:37:05Z
Yes, it would fail before getting to the assertion with: *Object of class Closure could not be converted to int*.
However, this is something good to test for (and document - test is a documentation). We're not checking if type is taken into account in other tests. This test might still fail if code inside removeListener() changed.
---------------------------------------------------------------------------
by vicb at 2013-02-10T11:42:29Z
I don't really understand your point and think it is a bit useless here but I am not against your change - I don't argue that test is doc though.
---------------------------------------------------------------------------
by jakzal at 2013-02-10T15:38:09Z
Assertion is indeed useless for the bug you discovered and fixed. I think it's still worth to have it there for other reason:
* test readability and completeness - with an assertion it's more clear that we don't expect the listener to be removed with the `removeListener()` call if passed argument doesn't match the one added before
If you still don't see my point just close this PR :)
---------------------------------------------------------------------------
by vicb at 2013-02-10T17:34:35Z
What I mean is that you are unit testing php and it is not a job for sf. So it is not strictly required but as it doesn't hurt, let's merge your change.
Jakub Zalas <notifications@github.com> wrote:
>Assertion is indeed useless for the bug you discovered and fixed. I
>think it's still worth to have it there for other reason:
>* test readability and completeness - with an assertion it's more clear
>that we don't expect the listener to be removed with the
>`removeListener()` call if passed argument doesn't match the one added
>before
>
>If you still don't see my point just close this PR :)
>
>
>---
>Reply to this email directly or view it on GitHub:
>https://github.com/symfony/symfony/pull/7038#issuecomment-13351469
This PR was merged into the 2.2 branch.
Commits
-------
73aa7d1 replaced usage of the deprecated pattern routing key (replaced with path)
Discussion
----------
replaced usage of the deprecated pattern routing key (replaced with path)
| 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
---------------------------------------------------------------------------
by lsmith77 at 2013-02-07T13:35:54Z
do we have tests to cover the BC behavior?
---------------------------------------------------------------------------
by fabpot at 2013-02-07T16:30:31Z
I've just added some tests for the legacy way.
This PR was submitted for the 2.2 branch but it was merged into the 2.1 branch instead (closes#7034).
Commits
-------
1fdded5 [HttpKernel] added support for the X-Forwarded-For header (closes#6982, closes#7000)
be65d7c [HttpKernel] fixed the IP address in HttpCache when calling the backend
Discussion
----------
Make HttpCache behaves more like a real reverse proxy
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #6982, #7000
| License | MIT
| Doc PR | n/a
---------------------------------------------------------------------------
by bendavies at 2013-02-10T00:55:29Z
Awesome, thanks Fabien. should this not target 2.0/2.1?
This PR was merged into the 2.2 branch.
Commits
-------
0e4a1fe updated required versions when depending on the HttpFoundation component
2704705 updated required versions when depending on the HttpKernel component
0a70fe7 updated required versions when depending on the Config component
2f1939b updated required versions when depending on the Form component
719628a updated required versions when depending on the DependencyInjection component
3db311a updated required versions when depending on the Validator component
a671313 updated required versions when depending on the Translation component
289ccfc updated required versions when depending on the Routing component
a742f0a updated required versions when depending on the EventDispatcher component
51857fe updated required versions when depending on the OptionsResolver component
20dfc15 updated required versions when depending on the PropertyAccess component
f971ccf updated required versions when depending on the Security component
da06817 updated required versions when depending on the Templating component
108a8c0 updated required versions when depending on the Stopwatch component
155cccb updated required versions when depending on the Process component
b95184b updated required versions when depending on the Finder component
a5da4a1 updated required versions when depending on the Dom Crawler component
0d74948 use ~2.0 when depending on the Dom Crawler component
d2d4c0a use ~2.1 when depending on the ClassLoader component
4def221 use ~2.0 when depending on the CSS selector component
9b64be2 use ~2.0 when depending on the locale component
c3906a4 updated required versions when depending on the Yaml component
Discussion
----------
Update Composer deps
| 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
Since we adopted Composer in Symfony, we limit the Symfony Components deps for any Symfony Component to the current version of Symfony. That's very limited as for instance, any version of Yaml can be used as a dependency for any other Symfony Component. So, this PR changes the version constraints for dependencies to the largest range possible.
The idea is also to open the range even more when new versions of Symfony comes.
---------------------------------------------------------------------------
by bamarni at 2013-02-08T17:40:41Z
👍closes#5891
---------------------------------------------------------------------------
by canni at 2013-02-08T23:42:04Z
👍
---------------------------------------------------------------------------
by simensen at 2013-02-09T05:35:41Z
👍
I think this is a great idea but it opens up the potential for internal version conflicts between components. The increased maintenance is probably worth it, though. :)
Several packages on Packagist are currently broken (see #6983) and I think this would fix that. A number of my projects have been forced back to 2.2@RC in favor of staying on 2.3@dev so I'm excited to see this resolved one way or another.
---------------------------------------------------------------------------
by vicb at 2013-02-09T10:06:36Z
Would the right way to fix this issue be semantic versioning ?
This PR was squashed before being merged into the 2.0 branch (closes#7023).
Commits
-------
87f3db7 [EventDispathcer] Fix removeListener
Discussion
----------
[EventDispathcer] Fix removeListener
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ~
| License | MIT
| Doc PR | ~
Todo
- [x] Add a UT
I won't have time to add a test before next Friday but this PR could save some debugging (especially with Silex & Closures)
---------------------------------------------------------------------------
by vicb at 2013-02-09T23:32:51Z
Probably related to https://bugs.php.net/bug.php?id=62976, I need to do some more investigation - I use 546. anyway the fix is valid for whatever php version.
---------------------------------------------------------------------------
by vicb at 2013-02-10T10:24:46Z
This **is** related to the PHP bug mentioned above, see http://3v4l.org/Q6WKj:
```
Output for 5.3.18 - 5.3.21, 5.4.8 - 5.5.0alpha4
bool(false)
Output for 5.3.0 - 5.3.17, 5.4.0 - 5.4.7
Notice: Object of class Klass could not be converted to int in /in/Q6WKj on line 9
Notice: Object of class Closure could not be converted to int in /in/Q6WKj on line 9
int(0)
```
@fabpot anything more needed to merge this ?
---------------------------------------------------------------------------
by fabpot at 2013-02-10T10:26:52Z
Is it possible to add a test?
---------------------------------------------------------------------------
by vicb at 2013-02-10T10:29:34Z
It is, for php versions < fixed version, I'll do that
---------------------------------------------------------------------------
by vicb at 2013-02-10T10:42:01Z
@fabpot ready Sir !
---------------------------------------------------------------------------
by vicb at 2013-02-10T10:44:35Z
well I can probably add an assert, please wait !
This PR was merged into the 2.2 branch.
Commits
-------
381bd7e [HttpFoundation] Added support for partial ranges in the BinaryFileResponse.
d9b9145 [HttpFoundation] Fixed byte ranges in the BinaryFileResponse.
Discussion
----------
2.2 binary response fixes
Fixes two problems described in #6961, related to handling requests with a *Range* header:
* BinaryFileResponse returns wrong number of bytes
* BinaryFileResponse incorrectly handles partial ranges
| Q | A |
|--------------|--------------------------------|
| Bug fix? | yes |
|New feature? | no |
|BC breaks? | no |
|Deprecations? | no |
|Tests pass? | yes |
|Fixed tickets | #6961 |
|License | MIT |
|Doc PR | n/a |
According to rfc2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.1)
byte positions are inclusive:
The first-byte-pos value in a byte-range-spec gives the byte-offset of
the first byte in a range. The last-byte-pos value gives the byte-offset
of the last byte in the range; that is, the byte positions specified are
inclusive. Byte offsets start at zero.
