Commits
-------
a450d00 [HttpFoundation] HTTP Basic authentication is broken with PHP as cgi/fastCGI under Apache
Discussion
----------
[HttpFoundation] HTTP Basic authentication is broken with php-cgi under Apache
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #1813
Todo: -
In order to work, add this to the .htaccess:
RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ app.php [QSA,L]
---------------------------------------------------------------------------
by stof at 2012-03-10T17:34:26Z
you should also add a unit test for this
---------------------------------------------------------------------------
by kepten at 2012-03-11T15:34:04Z
Thanks for the feedback, I committed the changes.
---------------------------------------------------------------------------
by stof at 2012-04-04T01:59:53Z
@fabpot could you review it ?
---------------------------------------------------------------------------
by fabpot at 2012-04-04T07:15:34Z
My comments:
* `ServerBag` represents what we have in the `$_SERVER` global variables. As such, the code should be moved to the `getHeaders()` method instead like the other tweaks we do for the HTTP headers.
* A comment must be added explaining why this is needed and the configuration the user must have to make it work (then remove the Github URLs).
* The code should only be executed when `PHP_AUTH_USER` is not available (to not have any overhead when not needed).
---------------------------------------------------------------------------
by danielholmes at 2012-04-14T13:27:09Z
A quick note on that .htaccess/apache configuration required, if adding to the Symfony SE htaccess file, then it will need to look like this:
```
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ app.php [QSA,L]
</IfModule>
```
NOTE: No **,L** in the Authorization Rewrite as in the original example - it prevents the front controller rewrite from happening
---------------------------------------------------------------------------
by towards at 2012-04-20T16:12:49Z
@kepten you were faster than me applying @fabpot's comments :) nevertheless part of the bug hunt day I also modified the ServerBag class and tested them on a productive LAMP hosting server using Apache and FastCGI
---------------------------------------------------------------------------
by kepten at 2012-04-20T16:15:57Z
ok, so is my PR is useless or should I still fix problems?
---------------------------------------------------------------------------
by towards at 2012-04-20T16:20:26Z
your PR is fine for sure and I don't want to interfere, just wanted to mention that part of the bug hunt day of Symfony I had a go at this PR as an "exercise" but just saw later on that you already fixed the problem, so you can ignore my pushes
---------------------------------------------------------------------------
by vicb at 2012-04-20T16:20:36Z
I have been working with @towards: your PR is useful, please implement his comments and squash your PR.
---------------------------------------------------------------------------
by kepten at 2012-04-20T16:59:07Z
never squashed before, is it okay now? :)
---------------------------------------------------------------------------
by stof at 2012-04-20T17:21:07Z
it is
---------------------------------------------------------------------------
by vicb at 2012-05-20T19:57:51Z
@fabpot this should be ready to be merged
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #1813
Todo: -
In order to work, add this to the .htaccess:
RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ app.php [QSA,L]
Commits
-------
d3f137b cosmetic tweak
2877883 anything in front of ;q= is part of the mime type, anything after may be ignored
Discussion
----------
[HttpFoundation] fix splitHttpAcceptHeader() parsing of parameters
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
anything in front of ;q= is part of the mime type, anything after may be ignored
see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
---------------------------------------------------------------------------
by lsmith77 at 2011/10/09 04:00:12 -0700
i must admit .. i am not 100% that my implemention is correct either .. but i am sure the current one isn't.
---------------------------------------------------------------------------
by lsmith77 at 2011/10/09 07:57:33 -0700
@fabpot: I am also not sure if getFormat() should optionally not support matching parameters, aka anything before ``;q=..``
Commits
-------
1283c47 [HttpFoundation] Fixed incorrect test; MimeTypeGuesser should be (and is) able to detect a path that is not a file also without the 'fileinfo' extension
Discussion
----------
[HttpFoundation] Fixed incorrect test when 'fileinfo' extension is not enabled
This test failed on my box with `fileinfo` disabled. The `FileNotFoundException` is thrown also when the `fileinfo`-extension is not enabled, so it should be expected.
Commits
-------
95011ce [HttpFoundation] Fixed creation of requests without a path.
Discussion
----------
[HttpFoundation] Fixed creation of requests without a path.
Providing urls with no path led to php warning that the index 'path' is
not set. This patch initializes 'path' if no path is set.
Commits
-------
d58ba34 [Validator] Consider the ini directive 'upload_max_filesize' while validating an uploaded file (fixes GH-1441)
Discussion
----------
[Validator] FileValidator support for uploaded files
[Validator] Consider the ini directive 'upload_max_filesize' while validating an uploaded file (fixes GH-1441)
Added validator messages should get translated in all the available languages.
Commits
-------
72c074a [Session] Used \Locale::setDefault() when the locale is setted
Discussion
----------
[Session] Used \Locale::setDefault() when the locale is setted
For `DateType` in form component (by example), `\Locale::getDefault()` is used to displayed the name of months.
If `\Locale` class is not used when the locale is setted in the session, the name of months is not in a good language.
This PR solves this problem.
---------------------------------------------------------------------------
by pborreli at 2011/05/29 09:13:44 -0700
what if user doesn't have intl extension ?
---------------------------------------------------------------------------
by stof at 2011/05/29 09:24:04 -0700
You should wrap the calls to ``\Locale::setDefault`` in a ``class_exist`` check to avoid issue when using the stub implementation (for which calling ``setDefault`` is forbidden).
---------------------------------------------------------------------------
by francisbesset at 2011/05/29 09:26:40 -0700
@pborreli: Symfony have a fake Locale class and this class is used only if the server haven't intl enabled.
---------------------------------------------------------------------------
by stof at 2011/05/29 09:33:16 -0700
@francisbesset Yeah, but ``setDefault`` throw a ``BadMethodCall`` exception.
and so the check has to use ``extension_loaded`` instead of ``class_exists``.
---------------------------------------------------------------------------
by fabpot at 2011/06/13 10:12:15 -0700
Ticket #1121 is related to this PR.
---------------------------------------------------------------------------
by fabpot at 2011/06/15 06:18:28 -0700
I have just tried another implementation where the locale is passed as an argument to the built-in types and some data transformers (via a `LocaleAwareInterface` interface). That works fine as forms are immutable now, but the solution is obviously more "complex" as we need to pass the locale to many different classes. Also, using `Locale::setDefault()` has an advantage over my method: you can change the locale whenever you want within a PHP process (which can be useful even if this is an edge case). Last, but not the least, if make sense to update the PHP Locale to the user locale.
So, to sum up, this patch is probably the best solution (easy and flexible enough).