This PR was merged into the 2.2 branch.
Discussion
----------
[Form] Fixed: The "data" option is taken into account even if it is NULL
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
Commits
-------
c1a3eb3 [Form] Fixed: The "data" option is taken into account even if it is NULL
This PR was merged into the 2.2 branch.
Discussion
----------
[DomCrawler] [HttpFoundation] Make `Content-Type` attributes identification case-insensitive
According to [section 3.7 of RFC 2616][], media-type attribute names in the `Content-Type` header are case-insensitive.
Therefore, identification of the `text` type and the `charset` parameter in the `Content-Type` header should be case-insensitive.
[section 3.7 of RFC 2616]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7
Commits
-------
17a2d66 [DomCrawler] [HttpFoundation] Make `Content-Type` attributes identification case-insensitive
This PR was merged into the 2.2 branch.
Discussion
----------
[2.2][Process] Fix#9343 : revert file handle usage on Windows platform
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #9343
| License | MIT
Hello,
I propose to revert the use of file handles only for `STDOUT` on Windows platform (see implementation in 2.2.6 [here](4059720232/src/Symfony/Component/Process/Process.php (L231-L242))).
When I decoupled pipes management from `Process` in #8924, I used file handles for both `STDOUT` and `STDERR`. This was an error as it introduced random failure in reading the handles (reported as [PHP#65650](https://bugs.php.net/bug.php?id=65650)).
Reverting to the previous implementation solves the issue. My apologies for the issues it introduced.
Versions that have been affected by the bug are 2.2.7, 2.2.8, 2.2.9, 2.3.4, 2.3.5 and 2.3.6.
Side note : I thought about testing the file handles implementation on *nix, but it fails most of the time where as Windows is okay. Unit testing on windows is okay (AbstractProcessTest::testProcessPipes tests it), but I don't provide a travis compatible test.
Commits
-------
e9dd408 [Process] Fix#9343 : revert file handle usage on Windows platform
My logs are filled with a bazillion errors stating "Warning: unlink(/var/www/mysite/app/cache/prod/http_cache/md/cf/47/c693da5dab3eccb65fa36a9b4b07ad0f7cc4.lck): No such file or directory in /var/www/mysite/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpCache/Store.php line 53"
This PR was merged into the 2.2 branch.
Discussion
----------
[Form] enforce correct timezone
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | not sure if this is a BC break...
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
I'm using the Form component to handle JSON requests which come from AJAX requests. The JSON is formed by the Angular toJson method
A typical request would be:
```
{
name: "Some name"
start: "2013-08-21T05:00:00.000Z"
end: "2013-08-21T15:00:00.000Z"
}
```
Note that in this case, what I entered in my input boxes are 7:00 for start and 17:00 for end times. As you can see, Angular (or Chrome, I'm not sure), converts this to the "Z" timezone. Since I cannot enforce the correct timezone client side, the timezone will differ from the one configured in the DateTimeType, however, instead of resulting in either an error or a conversion to the correct timezone, I get a datetime object in the wrong timezone, eventually resulting in wrong values in the database.
By checking the required output timezone against the actual timezone of the input datetime object, rather than the expected timezone supplied, this problem is solved.
Commits
-------
b0349a1 [Form] check the required output timezone against the actual timezone of the input datetime object, rather than the expected timezone supplied
This PR was merged into the 2.2 branch.
Discussion
----------
[HttpFoundation] Header `HTTP_X_FORWARDED_PROTO` can contain various values
Header `HTTP_X_FORWARDED_PROTO` can contain various values. Some proxies use `ssl` instead of `https`, as well as Lighttpd mod_proxy allows value chaining (`https, http`, where `https` is always first when request is encrypted).
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Tests pass? | yes
| Fixed tickets | #9101
| License | MIT
Commits
-------
d997443 [HttpFoundation] Header `HTTP_X_FORWARDED_PROTO` can contain various values Some proxies use `ssl` instead of `https`, as well as Lighttpd mod_proxy allows value chaining (`https, http`, where `https` is always first when request is encrypted).
Some proxies use `ssl` instead of `https`, as well as Lighttpd mod_proxy allows
value chaining (`https, http`, where `https` is always first when request is encrypted).
