replaced the proxy route with a listener #2179
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1 task
fabpot
added a commit
to symfony/symfony
that referenced
this pull request
Jan 23, 2013
This PR was merged into the master branch. Commits ------- 23f5145 renamed proxy to router_proxy e5135f6 [HttpKernel] renamed path to _path to avoid collision 3193a90 made the proxy path configurable ad82893 removed the need for a proxy route for rendering strategies b9f0e17 [HttpKernel] made the Request required when using rendering strategies Discussion ---------- Content renderer simplification | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | n/a | License | MIT | Doc PR | symfony/symfony-docs#2179 Todo: - [x] submit a PR for documentation update The first commit makes the Request required when dealing with rendering strategies (see the commit why this was a bad idea to make it optional in the first place). The second commit removes the need for a proxy route and replaces it with the same system we have in the security component. The third commit makes the proxy path configurable (default to `/_proxy`). This PR has been triggered by a discussion on #6791. --------------------------------------------------------------------------- by fabpot at 2013-01-22T09:49:37Z My opinion: * The first commit should be merged. * For the second and third one, I don't have a strong opinion. One of the benefits that the content renderer and its strategies do not rely on the Routing component anymore. --------------------------------------------------------------------------- by fabpot at 2013-01-22T15:22:47Z Any comments? ping @Tobion @vicb --------------------------------------------------------------------------- by Tobion at 2013-01-22T16:07:15Z Shouldn't the class name be like `SubRequestRenderingStrategyInterface` because currently it does not say anything about what is rendered. `RenderingStrategyInterface` makes it look like it's for rendering a normal master request, i.e. templating. --------------------------------------------------------------------------- by fabpot at 2013-01-22T16:19:26Z @Tobion: This was actually the first name I had but I found it too long. It is indeed rendering a normal request, but only in the context of a master request. --------------------------------------------------------------------------- by Tobion at 2013-01-22T16:23:25Z I found the correct term for what this is about: http://en.wikipedia.org/wiki/Transclusion So it should probably be like `Symfony/Component/HttpKernel/Transclusion/TransclusionInterface` or `TransclusionStrategyInterface`. So the term `rendering` is misleading as it does not really render the subrequest, but only prints a reference to the subrequest. The rendering is done by ESI processor or hinclude etc. --------------------------------------------------------------------------- by fabpot at 2013-01-22T16:37:00Z The `RenderingStrategyInterface` does render a request and returns a Response. One of the strategy consist of returning an ESI tag, but this is still a Response. I don't like introducing the `Transclusion` word as (at least for me) it does not evoke anything. --------------------------------------------------------------------------- by Tobion at 2013-01-22T16:46:10Z Also `DefaultRenderingStrategy` is not saying anything. What is default? It should express that it directly includes the resource in the other (term `integrate` comes to my mind). --------------------------------------------------------------------------- by kriswallsmith at 2013-01-22T17:23:21Z How about `InlineRenderingStrategy`? --------------------------------------------------------------------------- by vicb at 2013-01-22T17:25:17Z @Tobion @kriswallsmith 👍 --------------------------------------------------------------------------- by kriswallsmith at 2013-01-22T17:26:17Z Also, `SubRequestStrategyInterface` may be more apparent (`InlineSubRequestStrategy`, `EsiSubRequestStrategy`…) --------------------------------------------------------------------------- by Tobion at 2013-01-22T18:10:19Z `SubRequestStrategyInterface` is missing the verb somehow. A strategy for what? @kriswallsmith as an English native speaker, is transclusion also not convenient for you? --------------------------------------------------------------------------- by fabpot at 2013-01-22T18:11:41Z Thanks for all your suggestions, I appreciate them, but what about the whole approach? Do you agree that it is better than the current one? I'd like to avoid the bikeshedding if the approach is not better. --------------------------------------------------------------------------- by kriswallsmith at 2013-01-22T18:22:47Z :+1: for removing the router dependency. @Tobion perhaps request is the verb there? --------------------------------------------------------------------------- by Tobion at 2013-01-22T19:51:20Z I'm also fine with making it independent from the routing component because routing is about making routes configurable with placeholders etc. for nice URLs. But this is not needed for a proxy feature. --------------------------------------------------------------------------- by kriswallsmith at 2013-01-22T20:13:48Z @fabpot Do you anticipate ever wanting a sub request to be handled differently based on HTTP method? Just thinking of possible reasons to continue using the routing component here… --------------------------------------------------------------------------- by fabpot at 2013-01-22T20:40:06Z No, sub-requests only make sense for GET requests. In fact, we even enforce that in HttpContentRenderer. --------------------------------------------------------------------------- by fabpot at 2013-01-23T06:51:54Z I'm not going to discuss names further in the context of this PR as it has already been discussed in the initial PR that introduced these classes and because this PR does not change anything to the meaning of these classes. If you think the names can be better, feel free to open a ticket and discuss names there. --------------------------------------------------------------------------- by vicb at 2013-01-23T07:48:36Z If I understand correctly, both hsi and esi will generate path starting with "/_proxy", isn't it a problem wrt access_control ? should it be possible to configure a per strategy path ? --------------------------------------------------------------------------- by fabpot at 2013-01-23T07:56:11Z @vicb: Yes, all strategies use the `/_proxy` path when the developer uses a controller reference. But the router proxy takes care of securing the route, so there is no need to do it yourself. --------------------------------------------------------------------------- by vicb at 2013-01-23T08:07:36Z @fabpot that's smart, I've missed it. Some questions though (they should be answered by UT I think - and might already have been, I have not checked) - Isn't there a pb with urlencoding in the listener ? - Would the listener work with fragments (`#...') ? --------------------------------------------------------------------------- by vicb at 2013-01-23T08:31:37Z Some more points: - Should we validate that the router_proxy is enabled when esi are enabled (early failure ?) - Should we be able to enable each strategy individually (ie no need to expose the signer when hsi are not used) --------------------------------------------------------------------------- by fabpot at 2013-01-23T09:58:45Z Enabling the router proxy when using ESI si not required. The router proxy is "only" required when you use the `controller` Twig function (or the equivalent in PHP -> `ControllerReference`). But we can probably throw an exception in the `ControllerReference` constructor if the proxy is not enabled. Enabling each strategy individually is indeed a good idea (and that's more a general question as we could do the same for the translator loaders, or the service container loaders). Let's create another issue on this global topic. --------------------------------------------------------------------------- by vicb at 2013-01-23T10:10:29Z > But we can probably throw an exception in the ControllerReference constructor if the proxy is not enabled. It should probably be in a wrapper class then ? --------------------------------------------------------------------------- by fabpot at 2013-01-23T12:45:36Z The listener does not need to work with fragments as URLs as they are never part of the generated URL.
fabpot
added a commit
that referenced
this pull request
Jan 24, 2013
This PR was merged into the master branch. Commits ------- 7ab8be5 replaced the proxy route with a listener Discussion ---------- replaced the proxy route with a listener see symfony/symfony#6829
| # app/config/config.yml | ||
| framework: | ||
| # ... | ||
| router_proxy: { path: /_proxy } |
fabpot
added a commit
to symfony/web-profiler-bundle
that referenced
this pull request
Feb 11, 2013
This PR was merged into the master branch. Commits ------- 23f5145 renamed proxy to router_proxy e5135f6 [HttpKernel] renamed path to _path to avoid collision 3193a90 made the proxy path configurable ad82893 removed the need for a proxy route for rendering strategies b9f0e17 [HttpKernel] made the Request required when using rendering strategies Discussion ---------- Content renderer simplification | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | n/a | License | MIT | Doc PR | symfony/symfony-docs#2179 Todo: - [x] submit a PR for documentation update The first commit makes the Request required when dealing with rendering strategies (see the commit why this was a bad idea to make it optional in the first place). The second commit removes the need for a proxy route and replaces it with the same system we have in the security component. The third commit makes the proxy path configurable (default to `/_proxy`). This PR has been triggered by a discussion on #6791. --------------------------------------------------------------------------- by fabpot at 2013-01-22T09:49:37Z My opinion: * The first commit should be merged. * For the second and third one, I don't have a strong opinion. One of the benefits that the content renderer and its strategies do not rely on the Routing component anymore. --------------------------------------------------------------------------- by fabpot at 2013-01-22T15:22:47Z Any comments? ping @Tobion @vicb --------------------------------------------------------------------------- by Tobion at 2013-01-22T16:07:15Z Shouldn't the class name be like `SubRequestRenderingStrategyInterface` because currently it does not say anything about what is rendered. `RenderingStrategyInterface` makes it look like it's for rendering a normal master request, i.e. templating. --------------------------------------------------------------------------- by fabpot at 2013-01-22T16:19:26Z @Tobion: This was actually the first name I had but I found it too long. It is indeed rendering a normal request, but only in the context of a master request. --------------------------------------------------------------------------- by Tobion at 2013-01-22T16:23:25Z I found the correct term for what this is about: http://en.wikipedia.org/wiki/Transclusion So it should probably be like `Symfony/Component/HttpKernel/Transclusion/TransclusionInterface` or `TransclusionStrategyInterface`. So the term `rendering` is misleading as it does not really render the subrequest, but only prints a reference to the subrequest. The rendering is done by ESI processor or hinclude etc. --------------------------------------------------------------------------- by fabpot at 2013-01-22T16:37:00Z The `RenderingStrategyInterface` does render a request and returns a Response. One of the strategy consist of returning an ESI tag, but this is still a Response. I don't like introducing the `Transclusion` word as (at least for me) it does not evoke anything. --------------------------------------------------------------------------- by Tobion at 2013-01-22T16:46:10Z Also `DefaultRenderingStrategy` is not saying anything. What is default? It should express that it directly includes the resource in the other (term `integrate` comes to my mind). --------------------------------------------------------------------------- by kriswallsmith at 2013-01-22T17:23:21Z How about `InlineRenderingStrategy`? --------------------------------------------------------------------------- by vicb at 2013-01-22T17:25:17Z @Tobion @kriswallsmith 👍 --------------------------------------------------------------------------- by kriswallsmith at 2013-01-22T17:26:17Z Also, `SubRequestStrategyInterface` may be more apparent (`InlineSubRequestStrategy`, `EsiSubRequestStrategy`…) --------------------------------------------------------------------------- by Tobion at 2013-01-22T18:10:19Z `SubRequestStrategyInterface` is missing the verb somehow. A strategy for what? @kriswallsmith as an English native speaker, is transclusion also not convenient for you? --------------------------------------------------------------------------- by fabpot at 2013-01-22T18:11:41Z Thanks for all your suggestions, I appreciate them, but what about the whole approach? Do you agree that it is better than the current one? I'd like to avoid the bikeshedding if the approach is not better. --------------------------------------------------------------------------- by kriswallsmith at 2013-01-22T18:22:47Z :+1: for removing the router dependency. @Tobion perhaps request is the verb there? --------------------------------------------------------------------------- by Tobion at 2013-01-22T19:51:20Z I'm also fine with making it independent from the routing component because routing is about making routes configurable with placeholders etc. for nice URLs. But this is not needed for a proxy feature. --------------------------------------------------------------------------- by kriswallsmith at 2013-01-22T20:13:48Z @fabpot Do you anticipate ever wanting a sub request to be handled differently based on HTTP method? Just thinking of possible reasons to continue using the routing component here… --------------------------------------------------------------------------- by fabpot at 2013-01-22T20:40:06Z No, sub-requests only make sense for GET requests. In fact, we even enforce that in HttpContentRenderer. --------------------------------------------------------------------------- by fabpot at 2013-01-23T06:51:54Z I'm not going to discuss names further in the context of this PR as it has already been discussed in the initial PR that introduced these classes and because this PR does not change anything to the meaning of these classes. If you think the names can be better, feel free to open a ticket and discuss names there. --------------------------------------------------------------------------- by vicb at 2013-01-23T07:48:36Z If I understand correctly, both hsi and esi will generate path starting with "/_proxy", isn't it a problem wrt access_control ? should it be possible to configure a per strategy path ? --------------------------------------------------------------------------- by fabpot at 2013-01-23T07:56:11Z @vicb: Yes, all strategies use the `/_proxy` path when the developer uses a controller reference. But the router proxy takes care of securing the route, so there is no need to do it yourself. --------------------------------------------------------------------------- by vicb at 2013-01-23T08:07:36Z @fabpot that's smart, I've missed it. Some questions though (they should be answered by UT I think - and might already have been, I have not checked) - Isn't there a pb with urlencoding in the listener ? - Would the listener work with fragments (`#...') ? --------------------------------------------------------------------------- by vicb at 2013-01-23T08:31:37Z Some more points: - Should we validate that the router_proxy is enabled when esi are enabled (early failure ?) - Should we be able to enable each strategy individually (ie no need to expose the signer when hsi are not used) --------------------------------------------------------------------------- by fabpot at 2013-01-23T09:58:45Z Enabling the router proxy when using ESI si not required. The router proxy is "only" required when you use the `controller` Twig function (or the equivalent in PHP -> `ControllerReference`). But we can probably throw an exception in the `ControllerReference` constructor if the proxy is not enabled. Enabling each strategy individually is indeed a good idea (and that's more a general question as we could do the same for the translator loaders, or the service container loaders). Let's create another issue on this global topic. --------------------------------------------------------------------------- by vicb at 2013-01-23T10:10:29Z > But we can probably throw an exception in the ControllerReference constructor if the proxy is not enabled. It should probably be in a wrapper class then ? --------------------------------------------------------------------------- by fabpot at 2013-01-23T12:45:36Z The listener does not need to work with fragments as URLs as they are never part of the generated URL.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
see symfony/symfony#6829