[HttpKernel] hinclude fragment renderer must escape URIs properly to return valid html
fixed HInclude renderer (closes #7113)
[FrameworkBundle] Fix a BC for Hinclude global template
[DomCrawler] lowered parsed protocol string (fixes #6986)
merged branch cloppy/Dom-Crawler-fix (PR #7127)

This PR was merged into the 2.0 branch.

Commits
-------

cb03074 [DomCrawler] lowered parsed protocol string (fixes #6986)

Discussion
----------

[DomCrawler] lowered parsed protocol string (fixes #6986)

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #6986
| License       | MIT
| Doc PR        | symfony/symfony-docs#123

Are UTs needed for this?
added a note about a BC break for the path info of sub-request (closes #7138)
merged branch jfcixmedia/2.1 (PR #5838)

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

Commits
-------

201f3e6 [Form] Fixed cannot unset string offsets in CsrfValidationListener

Discussion
----------

[Form] Fixed cannot unset string offsets in CsrfValidationListener

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: -

A php fatal error is happening when someone rewrite the entire form data for an object with a single input.
```
Fatal error: Cannot unset string offsets in vendor/symfony/symfony/src/Symfony/Component/Form/Extension/Csrf/EventListener/CsrfValidationListener.php on line 72
```

Example:

```html
<form action="/app_dev.php/post/create" method="post" >
    <div id="posttype">
        <div>
            <label for="posttype_name" class="required">Name</label>
            <input type="text" id="posttype_name" name="posttype[name]" required="required" maxlength="255" />
        </div>
        <div>
            <label for="posttype_text" class="required">Text</label>
            <textarea id="posttype_text" name="posttype[text]" required="required"></textarea>
        </div>
        <input type="hidden" id="posttype__token" name="posttype[_token]" value="83a1617c694fbdea43c2527f1a55c7419ce82a42" /></div>
        <p>
            <button type="submit">Create</button>
        </p>
</form>
```

If someone alters the html to add a simple input at the bottom of the form like this one:
```html
<input type="text" id="posttype" name="posttype" value="test123" />
```

The result will be a php fatal error.

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

by bschussek at 2012-10-26T09:49:05Z

Thank you for the pull request! Could you please reference the pull request in the test?

```php
// https://github.com/symfony/symfony/pull/5838
public function testStringFormData()
{
    ...
```

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

by jfcixmedia at 2012-10-26T10:21:29Z

@bschussek  Added, thanks.
Added greek translation
merged branch psampaz/master (PR #7120)

This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes #7120).

Commits
-------

e5f063c Added greek translation

Discussion
----------

 Created validators.el.xlf

 Greek translation of validators
merged branch vicb/hinclude/global_template (PR #7119)

This PR was merged into the 2.2 branch.

Commits
-------

171cff0 [FrameworkBundle] Fix a BC for Hinclude global template

Discussion
----------

[FrameworkBundle] Fix a BC break for Hinclude global template

@fabpot should the one who broke BC write a UT for this ? (I won't have time in the next few days).
merged branch fabpot/hinclude-fix (PR #7116)

This PR was merged into the 2.2 branch.

Commits
-------

3933912 fixed HInclude renderer (closes #7113)

Discussion
----------

fixed HInclude renderer (closes #7113)

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #7113
| License       | MIT
| Doc PR        | n/a

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

by stof at 2013-02-19T08:36:20Z

:+1:
merged branch Tobion/fragment-render-escaping (PR #7090)

This PR was merged into the 2.2 branch.

Commits
-------

54d7d25 [HttpKernel] hinclude fragment renderer must escape URIs properly to return valid html

Discussion
----------

[HttpKernel] hinclude fragment renderer must escape URIs properly to return valid html

| Q             | A
| ------------- | ---
| Bug fix?      | [yes]
| New feature?  | [no]
| BC breaks?    | [no]
| Deprecations? | [no]
| Tests pass?   | [yes]
| Fixed tickets | [-]
| License       | MIT
| Doc PR        | [-]

Since rendering of hinclude fragments returns html/xml, it is marked as safe. So it's not auto-escaped of course. But that means it must properly escape it's input (the URI) when outputting in html context.
Btw, this does not need to be done for esi because esi tags are processed in middleware which do not go to the client/browser.

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

by Koc at 2013-02-15T22:59:05Z

Will it works correct when `arg_separator.output="&amp;"`?

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

by stof at 2013-02-15T23:04:01Z

if your url comes form the routing, yes. It [does not rely on the default separator](https://github.com/symfony/Routing/blob/master/Generator/UrlGenerator.php#L265) to avoid issues when the separator is configured to ``&amp;`` as it would have been escaped again in Twig templates for instance.

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

by fabpot at 2013-02-16T07:26:19Z

Can you include the proper PR header in the description? Thanks.

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

by Tobion at 2013-02-16T12:28:18Z

Added.
[Form] Fixed "label" option to accept the value "0"
merged branch bschussek/issue6862 (PR #7150)

This PR was merged into the 2.0 branch.

Commits
-------

f8812b2 [Form] Fixed "label" option to accept the value "0"

Discussion
----------

[Form] Fixed "label" option to accept the value "0"

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #6862
| License       | MIT
| Doc PR        | -

@fabpot: This commit will cause troubles when merging 2.0 into 2.1 and up. Tell me if you need help upon conflict resolution.
Fix docblock type
merged branch Maks3w/patch-5 (PR #7151)

This PR was submitted for the master branch but it was merged into the 2.1 branch instead (closes #7151).

Commits
-------

766e987 Fix docblock type

Discussion
----------

Fix docblock type
Expanded fault-tolerance for unusual cookie dates
merged branch TrackIF/master (PR #7149)

This PR was submitted for the master branch but it was merged into the 2.1 branch instead (closes #7149).

Commits
-------

0c25d41 Expanded fault-tolerance for unusual cookie dates

Discussion
----------

Expanded fault-tolerance for unusual cookie dates

Building on pull #1793, this resolves situations where the Cookie's date field uses a numeric month. Also, expanding on the 7 most typical formats we fall-back to date_create() before throwing an exception.

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

by vicb at 2013-02-21T17:30:28Z

Please add some unit tests for the new formats.

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

by ecaron at 2013-02-21T18:06:46Z

Sorry for neglecting the unit tests, they've been updated (2 matching new common date formats, 1 uncommon date format, and changing the existing bad-date check to be more realistically bad.)

I also changed from strtotime to date_create to match the existing DateTime::createFromFormat check (although in my cookiejar analysis leading to this pull requests, all the cookies I'd encountered had timezones in them.) I'm using date_create vs. constructing a DateTime so I can immediately rely on the return value.

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

by ecaron at 2013-02-21T18:21:03Z

@vicb The two Travis failures are against the master branch unrelated to my changes. Should I retarget this pull against 2.3, or what would you advise to get this pull accepted?

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

by vicb at 2013-02-21T19:40:59Z

The Travis failure come for a bug in PHPUnit (there is a Sf issue for that).

There is no 2.3 branch yet (devs happen in master).

@fabpot will decide wether this should be considered a a fix (and merge to former releases) or an enhancement which will be merged to 2.3.

_(Could you please update the PR header which still refers to strtotime, thanks)_

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

by fabpot at 2013-02-21T21:37:15Z

This should probably go into 2.0. Also, do you have a reference where those 7 formats are explained/described?

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

by ecaron at 2013-02-21T23:10:38Z

@fabpot I couldn't find a reference because the cookies that we're addressing are ones that are behaving outside the spec (at least what I understand from http://curl.haxx.se/rfc/cookie_spec.html), as pull #1793 began to address and this continues. The cases that I've added are ones that I have encountered over the weeks of using BrowserKit and Goutte.
[Form] Added test for "label" option to accept the value "0"
merged branch bschussek/issue6862 (PR #7154)

This PR was merged into the 2.1 branch.

Commits
-------

00fbb7e [Form] Added test for "label" option to accept the value "0"

Discussion
----------

[Form] Added test for "label" option to accept the value "0"

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #6862
| License       | MIT
| Doc PR        | -