As some background, the method was changed to regex to be consistent with
the other requirements (though admittedly, it *is* different than the other
requirements and is generally handled internally in a slightly different
way). So the rationale behind the change really fell to
documentation/training. It comes down to this:
* without regex
requirements:
language: en|fr
_method: [get, head]
* with regex:
requirements:
language; en|fr
_method: get|head
In general, I like that this change is more proper to the HTTP spec, so I'll
defer to what everyone else thinks. Just keep in mind the above
inconsistency. The problem could also be solved (this may already be in the
PR) by throwing an exception with good language if the _method requirement
is a string (this was not done well in sf1).
Thanks!
Ryan Weaver
Lead Programmer - iostudio - Nashville, TN
http://www.iostudio.com
http://www.thatsquality.com
Twitter: @weaverryan
On Mon, Feb 28, 2011 at 2:26 PM, Jordi Boggiano <[email protected]> wrote:
> On 28.02.2011 19:56, Kris Wallsmith wrote:
> >>> Additionally, I've reverted Ryan's earlier patch that changed the
> syntax
> >>> for defining a _method requirement so it is now either a string or
> array
> >>> once again, no longer a case-insensitive regular expression.
> >>
> >> I don't agree with that one. Requirements are defined as regexes, and
> >> having one of them behave differently is counter-intuitive. Given that
> >> mostly everyone will just do stuff like "GET|POST" anyway, I don't think
> >> it hinders the display of the exception message.
> > According to the the HTTP spec, a 405 response "MUST include an Allow
> > header containing a list of valid methods for the requested resource."
> > This is not be possible if the requirement is a regular expression.
> > Furthermore, _method was already a special requirement because it was
> > case-insensitive, while all others are case-sensitive.
>
> Fair enough I guess. It's a detail I won't fight over it :) But we could
> in theory support only *|*|* as a regex, and split on | to get all
> possible variants.
>
> Cheers
>
> --
> Jordi Boggiano
> @seldaek :: http://seld.be/
>
> --
> If you want to report a vulnerability issue on symfony, please send it to
> security at symfony-project.com
>
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
