Better recognize urls#93
Conversation
|
@julianrubisch - give this a review and see what you think. We might need to pair or take another crack at fully building up our request object and building the correct sequence of objects for the renderer. I noticed that the SR team changed, slightly, the way that the controllers and renderer is built up and implemented Middleware functionality. |
|
Do let me know if this is not clear enough to review or you need more information. |
|
Thanks! Will do, will have to defer this until Monday though |
|
One question: In what circumstance would you expect a POST/PUT etc. route to appear in the URL? I'm not sure I totally get it... |
|
Good question. Short answer is that I have no intention for that to happen, but it "could" happen, so I provided the option. The longer answer: Right now I can't use futurism in my app because the current implementation only passes the path (i.e. without the subdomain) to the The routes that I need it to recognize are currently all GET requests, but in theory, someone could have a POST/PUT/PATCH/DELETE. So... the way I implemented this is that it loops through all possible HTTP verbs to try to infer the correct route. |
|
Understood. Just wanted to make sure we don't overlook some security concern here. |
Bug fix
Description
This passes in the full url to the
Rails.application.routes.recognize_pathmethod and try multiple HTTP methods to try to match a URL.Note: While this does fix some bugs, it doesn't appear the
controllerandaction_nameare currently being passed through correctly to the underlying controller. I don't have failing tests for that, but it doesn't look like the code I wrote some time ago works properly.This PR does no harm -- it makes it better -- but it doesn't fully address the intended functionality. However, it does fix #89
Checklist