Micronaut-core: Feature request: possibility to handle custom HTTP methods

[Im-dex]

Hi! I'm trying to implement WebDAV server using micronaut, but unfortunately, I can't find out a way to handle non-standard HTTP methods like PROPFIND, REPORT etc. HttpMethod enumeration contains a fixed set of the methods and you can't extend it somehow. What about to add yet another method, for example, UNKNOWN, which could be handled then by controller handler with a custom routing logic?

[spirit-1984]

Working on it.

[spirit-1984]

There are basically two possibilities here. One is like that

@UNKNOWN
public String respond(
    @Method String method // Possibly other arguments
) { 
// Handle this
}

This means not only I have to patch the router, that does the matching, but also via reflection I should check, if the method requests for the name of non-standard HTTP method and provide it, if necessary. Seems hard to me. A better approach would be something like that:

@CustomMethod("PROPFIND")
public String process(// Provide here HttpRequest or something else, as standard micronaut methods
) {
}

This seems a little bit easier to me, I think I should implement this solution. Reasoning is - I cannot imagine the case that the server needs to catch absolutely all methods in the world (HTTP methods, Webdav methods and etc.). Usually you know the set of available methods and should provide a route for each of them, nothing more.

[graemerocher]

Latter approach seems better to me

[spirit-1984]

@graemerocher Hi, I spent a couple of hours and implemented this https://github.com/spirit-1984/micronaut-core/commit/7078e0f67d8fac41b470d4157a0b660b1676de87 in my fork. However, there is a problem - I made a major change, turning HttpMethod from enum to class, so that I could provide the name of the method. I need a little bit of advice, how to implement this correctly without such breaking changes before new major version. I think I should do it like this:

• Extend HttpMethod enum with new value CUSTOM.
• Extend HttpRequest - not only should it contain method name, but it also should contain default method String getMethodName, which returns the enum value.
• Change AbstractNettyHttpRequest constructor, so that it would now contain this name (this is actually the only place where conversion is made between Netty HttpMethod and Micronaut HttpMethod). This implementation should act as default for everything except custom.
• Rewrite DefaultUriRouter, which now should contain custom routes as well - that means change it's filtering methods for custom case.

I guess that's it. I'm not sure if I should change HttpClientIntroductionAdvice since that assumes interceptors for client, and I'm dealing with the server side here.

[spirit-1984]

OK, I've made it through minor changes https://github.com/spirit-1984/micronaut-core/commit/d0f77eaa9880ade2eb729e5b001ed029713bbc25 - but it turns out http client does not send non-standard methods correctly, so I do have to use HttpUrlConnection for now. I am going to implement the required changes for HttpClient too.

[graemerocher]

Thanks. Will take a look soon. I wonder if instead of introducing a new annotation we should just using HttpMethodMapping and make it more flexible to allow it to specify the method name etc.

[spirit-1984]

OK, I've managed to make DefaultHttpClient work fine with custom methods too. https://github.com/spirit-1984/micronaut-core/commit/853aba4f35d5ca8145f32cbae0a407fa5d353ba7 - and tests are running fine. Now I need just a little bit to patch HttpClientIntroductionAdvice so that it would support custom methods too, and run all the style checks and so on, and it will be ready for a pull request)

[spirit-1984]

Thanks. Will take a look soon. I wonder if instead of introducing a new annotation we should just using HttpMethodMapping and make it more flexible to allow it to specify the method name etc.

I am not sure about that. Primarily because HttpMethodMapping does not have a lot of members (like produces/consumes, for example). Adding them potentially cause problems to those, who use that annotation in their projects. So I would add an explicit custom tag indicating that this is a non-standard http method.

[spirit-1984]

@graemerocher I made a pull request that passed all the tests and code style checks in travis-ci. Also, if that could be merged to 1.2.x instead of 1.3.0, it would be just great.

[jameskleeh]

@spirit-1984 Can you update the documentation to include this new feature?

[spirit-1984]

@spirit-1984 Can you update the documentation to include this new feature?

Yeah, sure, will write a draft now