[HttpFoundation] Fixed byte ranges in the BinaryFileResponse.

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.
[HttpFoundation] Added support for partial ranges in the BinaryFileResponse.

Valid ranges include:
* bytes=0-499
* bytes=500-999
* bytes=-500
* bytes=9500-
* bytes=0-0
merged branch jakzal/2.2-binary-response-fixes (PR #7032)

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 |
[EventDispathcer] Fix removeListener
merged branch vicb/event (PR #7023)

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 !
[EventDispatcher] Added assertion.
added a proper setter for the templating servicein HInclude
merged branch fabpot/composer-deps (PR #7027)

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

:+1: closes #5891

---------------------------------------------------------------------------

by canni at 2013-02-08T23:42:04Z

:+1:

---------------------------------------------------------------------------

by simensen at 2013-02-09T05:35:41Z

:+1:

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 ?
Merge branch '2.2'

* 2.2: (30 commits)
  [HttpFoundation] Added support for partial ranges in the BinaryFileResponse.
  [HttpFoundation] Fixed byte ranges in the BinaryFileResponse.
  updated required versions when depending on the HttpFoundation component
  updated required versions when depending on the HttpKernel component
  updated required versions when depending on the Config component
  updated required versions when depending on the Form component
  updated required versions when depending on the DependencyInjection component
  updated required versions when depending on the Validator component
  updated required versions when depending on the Translation component
  updated required versions when depending on the Routing component
  updated required versions when depending on the EventDispatcher component
  updated required versions when depending on the OptionsResolver component
  updated required versions when depending on the PropertyAccess component
  updated required versions when depending on the Security component
  updated required versions when depending on the Templating component
  updated required versions when depending on the Stopwatch component
  updated required versions when depending on the Process component
  updated required versions when depending on the Finder component
  updated required versions when depending on the Dom Crawler component
  use ~2.0 when depending on the Dom Crawler component
  ...
changed dependencies to allow all 2.3 versions of the components (closes #6983)
fixed typos in composer.json version constraints
Merge branch '2.2'

* 2.2:
  fixed typos in composer.json version constraints

Conflicts:
	src/Symfony/Component/DependencyInjection/composer.json
	src/Symfony/Component/Routing/composer.json
fixed the IP address in HttpCache when calling the backend
added support for the X-Forwarded-For header (closes #6982, closes #7000)
merged branch fabpot/ip-cache (PR #7034)

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?
merged branch fabpot/pattern-fix (PR #6998)

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.
merged branch jakzal/2.0-event (PR #7038)

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
[Form]fixed FormRenderer::humanize() to humanize camel cased label
merged branch 77web/fix-form-renderer-humanize (PR #6992)

This PR was squashed before being merged into the master branch (closes #6992).

Commits
-------

8adb0e3 [Form]fixed FormRenderer::humanize() to humanize camel cased label

Discussion
----------

[Form]fixed FormRenderer::humanize() to humanize camel cased label

| 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

FormRenderer::humanize() only converts underscored_field_name to humanized field name(just the same as sfInflector::humanize()).
Sensio\Bundle\GeneratorBundle\Generator\DoctrineFormGenerator does not convert camelCased field names to underscored one, however.
I have to edit manually field names in the generated FormType class everytime I use doctrine:generate:form Command, too messy.
so I suggest humanize() is to take care of it.

---------------------------------------------------------------------------

by 77web at 2013-02-08T01:40:59Z

@vicb thank you for your kind review. I've added commits as you told.

---------------------------------------------------------------------------

by vicb at 2013-02-08T07:33:47Z

@77web you probably could merge the the setup into the test method.

---------------------------------------------------------------------------

by 77web at 2013-02-08T08:17:10Z

@vicb I've merged setUp() and tearDown() into test method(before and after assertion). anything else to fix?

---------------------------------------------------------------------------

by 77web at 2013-02-08T10:11:51Z

@vicb I've fixed test as you told.thanks again for your kind help!

---------------------------------------------------------------------------

by vicb at 2013-02-08T12:00:29Z

One last thing: a note in the changelog ?

---------------------------------------------------------------------------

by 77web at 2013-02-08T12:23:57Z

I added a note in 2.2.0 section. or shold I write it in 2.1.0?

---------------------------------------------------------------------------

by vicb at 2013-02-08T12:25:36Z

As you send it to master, you should create a 2.3.0 (2.1 & 2.2 have their own branches)

---------------------------------------------------------------------------

by vicb at 2013-02-08T12:26:40Z

and should write your comment as "fixed xyz to abc". Thanks.

---------------------------------------------------------------------------

by 77web at 2013-02-08T12:32:39Z

fixed my note. thanks a lot! @vicb
[Validator] Add check for existing metadata on property