merged branch gigablah/header_caps (PR #5662)

This PR was merged into the master branch.

Commits
-------

63a228c Map normalized header names to original capitalization

Discussion
----------

[HttpFoundation] Preserve capitalization of response header names

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: [![Build Status](https://secure.travis-ci.org/gigablah/symfony.png)](http://travis-ci.org/gigablah/symfony)
License of the code: MIT
Fixes the following tickets: -
Todo: -

`HeaderBag` normalizes header names when they are set. Therefore, custom header names (e.g. X-Sendfile, Vary) are output in lowercase. I've added an array to map header keys to their original capitalization in `ResponseHeaderBag`. Calling `allPreserveCase()` will now output the header array with capitalization preserved.

More of a cosmetic (and consistency) fix, since HTTP header names are case insensitive.

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

by pborreli at 2012-10-03T16:09:31Z

may not work with
```
ETag
Content-MD5
P3P
WWW-Authenticate
X-UA-Compatible
X-XSS-Protection
```

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

by fabpot at 2012-10-03T17:14:12Z

This overrhead is not needed most of the time. It should be done in a response listener if you have the issue. But as far as the RFC is concerned, this is not needed.

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

by gigablah at 2012-10-04T13:51:59Z

I've reworked my approach to account for the cases mentioned by @pborreli. `ResponseHeaderBag` now contains an array to map the header keys to their original capitalized names. This is much cleaner compared to string manipulation. I've also added a simple test case.

Please let me know if there's merit to this, failing which I'll just extend the class in my projects.

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

by fabpot at 2012-10-04T14:10:28Z

@gigablah This approach looks much better indeed.

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

by gigablah at 2012-10-04T15:29:29Z

Thanks! I've squashed the commits and added more test data.

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

by pborreli at 2012-10-04T15:49:05Z

Thank you, it's a nice PR :+1:
merged branch drak/docb (PR #5672)

This PR was merged into the 2.0 branch.

Commits
-------

22c7a91 [HttpKernel][Translator] Fixed type-hints

Discussion
----------

[HttpKernel][Translator] Fixed type-hints

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -

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

by drak at 2012-10-04T15:18:55Z

This PR is ready - the travis build fail is not related to this PR which is just docblock changes.

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

by pborreli at 2012-10-04T15:37:57Z

the travis build fail is indeed not related to your PR but your branch. see https://github.com/drak/symfony/blob/docb/.travis.yml

You should fetch upstream remote, merge, rebase and push again.

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

by drak at 2012-10-04T16:50:28Z

Thanks for the info, but the branch is 100% up to date with `2.0`, the file you quoted is as it is in the main repo: https://github.com/symfony/symfony/blob/2.0/.travis.yml - in any case, it doesnt affect merging this changeset.
merged branch fabpot/twig (PR #5660)

This PR was merged into the master branch.

Commits
-------

5c809d8 [TwigBundle] added support for Twig namespaced paths (Twig 1.10)

Discussion
----------

[TwigBundle] added support for Twig namespaced paths (Twig 1.10)

In a template, you can now use native Twig template names, instead of
the Symfony ones:

Before (still works):

    {% extends "AcmeDemoBundle::layout.html.twig" %}
    {% include "AcmeDemoBundle:Foo:bar.html.twig" %}

After:

    {% extends "@AcmeDemo/layout.html.twig" %}
    {% include "@AcmeDemo/Foo/bar.html.twig" %}

Using native template names is also faster.

The only drawback is that the new notation looks similar to the way we
locate resources in Symfony, which would be
`@AcmeDemoBundle/Resources/views/Foo/bar.html.twig`. We could have used
the same notation, but it is rather verbose (and by the way, using this
notation did not work anyway in templates).

TODO: update documentation

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

by fabpot at 2012-10-03T13:36:56Z

I forgot to mention why I'd like to include this change besides performance: this would allow to share templates between a project using the Symfony2 full-stack framework and any other project using Twig.

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

by henrikbjorn at 2012-10-03T13:50:48Z

:+1: Will the old notation be deprecated at some point?

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

by stof at 2012-10-03T14:29:50Z

@fabpot does it still support overwriting templates ?
merged branch docteurklein/fix-router-resolve-string (PR #4995)

This PR was merged into the master branch.

Commits
-------

4b86765 [FrameworkBundle] recursively resolve container parameter placeholders for arrays in router _defaults

Discussion
----------

[2.2] [FrameworkBundle] avoid trying to resolve container placeholders on arrays on router _defaults

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: ~
Todo: ~
License of the code: MIT
Documentation PR: ~

Permits to pass arrays in route `_defaults`.

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

by stof at 2012-07-20T13:07:36Z

This seems weird. An array could contain parameters in it.

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

by docteurklein at 2012-07-20T13:17:00Z

@stof An object too then, no ? Why accepting objects but not arrays ? Would you propose to recursively resolve array values ?

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

by stof at 2012-07-20T13:31:06Z

@docteurklein Resolving array values recursively would be consistent with the way the DIC parameters are resolved. I don't really see how you would resolve objects (and btw, it is pretty much an edge case as you cannot really put an object in your routes if you define them in your YAML or XML config files or with annotations)

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

by docteurklein at 2012-07-20T13:36:43Z

@stof I agree. I can manage recursive array resolving if needed.

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

by fabpot at 2012-07-23T13:58:07Z

Can you squash your commits before I merge? Thanks.

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

by docteurklein at 2012-07-23T14:39:17Z

@fabpot  done.
[Routing] fix handling of two starting slashes in the pattern

It would be confused with a network path e.g. '//domain/path' when generating a path so should be prevented.
[Console] fixed #5316
added doc comments
added doc comments
adds two convenience methods for optional configuration sections
fixed CS
added entry to changelog
merged branch schmittjoh/configConvenience (PR #5688)

This PR was merged into the master branch.

Commits
-------

36bbaf3 added entry to changelog
0187a1a adds two convenience methods for optional configuration sections

Discussion
----------

adds two convenience methods for optional configuration sections

This adds two convenience methods which safes some typing for optional configuration.

I have updated the FrameworkConfiguration to use these methods; the behavior is equivalent.

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

by sstok at 2012-10-06T12:21:09Z

:+1:

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

by fabpot at 2012-10-06T12:32:10Z

Looks good. Can you update the documentation as well and add a note in the component CHANGELOG? Thanks.

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

by schmittjoh at 2012-10-06T14:22:35Z

done
[Config] added some phpdocs
merged branch xrstf/2.0 (PR #5686)

This PR was merged into the 2.0 branch.

Commits
-------

b2614aa fixed CS
e7c2e90 added doc comments

Discussion
----------

added doc comments
Merge branch '2.0' into 2.1

* 2.0:
  fixed CS
  added doc comments
  [HttpKernel][Translator] Fixed type-hints
  [Translation] forced the catalogue to be regenerated when a resource is added (closes symfony/Translation#1)
  [HttpFoundation] Fixed #5611 - Request::splitHttpAcceptHeader incorrect result order.

Conflicts:
	src/Symfony/Component/Process/Process.php
	tests/Symfony/Tests/Component/HttpFoundation/RequestTest.php
merged branch xrstf/2.1 (PR #5687)

This PR was merged into the 2.1 branch.

Commits
-------

65cf3a0 added doc comments

Discussion
----------

added doc comments

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

by stof at 2012-10-06T11:27:23Z

closing in favor of #5686 which targets 2.0

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

by fabpot at 2012-10-06T12:38:17Z

This one cannot be closed as it contains more phpdocs than in the 2.0 branch.
Merge branch '2.1'

* 2.1:
  fixed CS
  added doc comments
  added doc comments
  [Validator] Updated swedish translation
  Update src/Symfony/Component/Validator/Resources/translations/validators.de.xlf
  [2.1] Exclude tests from zips via gitattributes
  [HttpKernel][Translator] Fixed type-hints
  Updated lithuanian validation translation
  [DomCrawler] Allows using multiselect through Form::setValues().
  [Translation] forced the catalogue to be regenerated when a resource is added (closes symfony/Translation#1)
  Unit test for patched method OptionsResolver::validateOptionValues().
  validateOptionValues throw a notice if an allowed value is set and the corresponding option isn't.
  [Form] Hardened code of ViolationMapper against errors
  [HttpFoundation] Fixed #5611 - Request::splitHttpAcceptHeader incorrect result order.
  [Form] Fixed negative index access in PropertyPathBuilder
  Update src/Symfony/Component/Validator/Resources/translations/validators.ro.xlf

Conflicts:
	src/Symfony/Component/DomCrawler/Form.php
	src/Symfony/Component/Process/Process.php
fixed typo
FIX [2.1][ClassLoader]UniversalClassLoader not working with AnnotationRegistry::registerLoader
[2.1][DependencyInjection] Incomplete error handling in the container