Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Allow Router to handle additional HTTP verbs/methods #1234

Closed
wants to merge 1 commit into from

Conversation

iStefo
Copy link

@iStefo iStefo commented Sep 27, 2015

After a brief discussion in this Stackoverflow thread, I continued trying adding custom HTTP methods to the Phoenix Router.

While this option surely comes as a danger (using custom HTTP methods is generally not a favourable desire), it may be necessary to implement some protocols that extend HTTP with own method names, such as WebDAV/CalDAV.

Allowing the programmer to add custom HTTP methods turned out to be more difficult than I originally thought, because the method macros are being generated at phoenix's compile time, and not the application's. That made it impossible to either use

use Phoenix.Router, additional_http_methods: [:move, :copy]

or

defmodule Router do
    @additional_http_methods [:move, :copy]
    use Phoenix.Router
end

However, the current approach uses the projects config files and by adding this command adds any custom methods as desired by the programmer:

# Add additional HTTP methods
config :phoenix, :router,
  additional_http_methods: [:move, :copy]

A short list of tasks that came up to my mind:

  • Documentation (Possible in the Router's guide)
  • Tests (I don't know how to stub the Application.get_env call to simulate such a config as above)
  • The CSRF Plug denies any requests with a custom HTTP Method without a valid CSRF token (this is not a blocker but it would be nice to at least mention this somewhere, right?)

Please tell me what you think about this addition.

In the __before_compile__ macro, Phoenix.Router can retrieve additional http methods and create the macros just as with the stock methods.
@josevalim
Copy link
Member

Another approach is to have a match :verb, ... construct that would allow you to provide any HTTP verb without a need to recompile Phoenix. It should be simpler on Phoenix side too.

@iStefo
Copy link
Author

iStefo commented Sep 27, 2015

@josevalim I see why it would be desirable to add methods without recompiling phoenix, I can't judge the internal complexity, though.

However, creating specific macros that are nicer to use than a generic match construct would be in the spirit of having a nice DSL for the project, wouldn't it?

@josevalim
Copy link
Member

@iStefo if we have match(:verb) then you can create your own macros if you want. :)

@chrismccord
Copy link
Member

👍 on match primitive. If we are to support this it should be based on a public primitive and not options or module attributes

@iStefo
Copy link
Author

iStefo commented Sep 27, 2015

Alright, as long as it is possible to create the DSL-like macros, I am in for the match primitive.

Do you see any way I can push this forward and help with the implementation? Or are the internals rather complex for a beginner like me?

@chrismccord
Copy link
Member

Do you see any way I can push this forward and help with the implementation? Or are the internals rather complex for a beginner like me?

Unfortunately the router is the most complex bits of phoenix so it might be a lot to take on, but you are welcome to give it a shot. Otherwise, please open a separate issue and I can take care of it :)

@iStefo
Copy link
Author

iStefo commented Sep 28, 2015

@chrismccord since I have rather little time in the near future to take care of this enhancement, I will gladly open an issue and leave it to people more close to the Router module.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants