Ahoi, Talked with Jordi over lunch about this some more. There are three kinds of internal subrequests that we were aware of: 1) forward 2) render with standalone false 3) render with standalone true
We discussed that it would make sense to optionally support using a path instead of a controller+action for all of the above. Obviously this adds overhead since the route has to be matched etc, however 1) These are really "internal redirects", the use cases are fairly rare, mostly I see them relevant for cases where for html you want an "external redirect" when the format is html. So here using a a forward is already faster than an external redirect. So maybe not so much an issue? For cases where you dont really care about security you could just as well just make an instance of the controller and call the action yourself. 2) Here we would just document that if you are not using a path, you are ignoring security, but when using a path security controls would be applied 3) Here we would not allow the current syntax, but would require the path syntax. This way we can also apply the same security controls without any extra configuration on ESI requests regards, Lukas Kahwe Smith [email protected] -- 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
