In the current implementation, any request whose method is not one of NanoHTTPD's Method enum names is automatically rejected.
I propose that this is a mistake. HTTP defines a standard minimal set of methods... but it's not uncommon for services to use other methods from proposed standards that are not yet accepted into the core spec, and may or may not be listed in the HTTP method registry. In fact, the current definition of Method includes quite a few verbs that are in neither one, like PROPGET and SUBSCRIBE.
Since the shape of an HTTP request is well defined, a server framework should be able to read the request first, and then let the application logic decide whether it's possible to handle a request with that method. Since NanoHTTPD doesn't include any kind of routing feature, it is already leaving it up to the application to decide whether a given endpoint URL should allow GET, PUT, PATCH, all of the above, etc.; I'm not sure what value is being added by rejecting a request with an unrecognized method before the application can see it.
I have a specific use case where this is a problem for me: there is a web service that uses the REPORT method (which is from the now-obscure WebDAV protocol, and is listed in the method registry), and I need to be able to simulate this service when I'm testing client-side logic. NanoHTTPD would be great for my test code in every other way, but it can't handle REPORT. A short-term solution would be to add REPORT (and, preferably, everything else that's in the method registry) to the Method enum— but I feel like that is still not a great solution in the long run. I would greatly prefer for Method to be a non-enum type that provides some static known values but also allows other values to be represented, so that the usability of the library is not dependent on whether the maintainers happen to have heard of some particular rarely-used verb.
In the current implementation, any request whose method is not one of NanoHTTPD's
Methodenum names is automatically rejected.I propose that this is a mistake. HTTP defines a standard minimal set of methods... but it's not uncommon for services to use other methods from proposed standards that are not yet accepted into the core spec, and may or may not be listed in the HTTP method registry. In fact, the current definition of
Methodincludes quite a few verbs that are in neither one, likePROPGETandSUBSCRIBE.Since the shape of an HTTP request is well defined, a server framework should be able to read the request first, and then let the application logic decide whether it's possible to handle a request with that method. Since NanoHTTPD doesn't include any kind of routing feature, it is already leaving it up to the application to decide whether a given endpoint URL should allow GET, PUT, PATCH, all of the above, etc.; I'm not sure what value is being added by rejecting a request with an unrecognized method before the application can see it.
I have a specific use case where this is a problem for me: there is a web service that uses the
REPORTmethod (which is from the now-obscure WebDAV protocol, and is listed in the method registry), and I need to be able to simulate this service when I'm testing client-side logic. NanoHTTPD would be great for my test code in every other way, but it can't handleREPORT. A short-term solution would be to addREPORT(and, preferably, everything else that's in the method registry) to theMethodenum— but I feel like that is still not a great solution in the long run. I would greatly prefer forMethodto be a non-enum type that provides some static known values but also allows other values to be represented, so that the usability of the library is not dependent on whether the maintainers happen to have heard of some particular rarely-used verb.