ResourceResolver::resolveNode does not match empty method

[rljonesau]

Your REST API example demonstrates a node with no defined method or path.
I tried a node with a defined path but no method, expecting the handler to then switch upon GET or POST when accessing the path.

The node resolver fails to allow such a match to take place.

Suggested change is to add a match condition for an empty method in the node:

  if (node->_nodeType==nodeType) {
      if (
        // For handler functions, check the method declared with the node
        (node->_nodeType==HANDLER_CALLBACK && ((ResourceNode*)node)->_method == method) ||
        // For websockets, the specification says that GET is the only choice
        (node->_nodeType==WEBSOCKET && method=="GET") ||
      ) {

to

  if (node->_nodeType==nodeType) {
      if (
        // For handler functions, check the method declared with the node
        (node->_nodeType==HANDLER_CALLBACK && ((ResourceNode*)node)->_method == method) ||
        // For websockets, the specification says that GET is the only choice
        (node->_nodeType==WEBSOCKET && method=="GET") ||
        // handler must decode method
        (node->_nodeType==HANDLER_CALLBACK && ((ResourceNode*)node)->_method == "") 
      ) {

[fhessel]

The REST-API example defines such a node, but uses it as default node, meaning it's the fallback if no other node matches:

  ResourceNode * spiffsNode = new ResourceNode("", "", &handleSPIFFS);
  secureServer->setDefaultNode(spiffsNode);

As the main reason for having such a default node is to handle non-matching requests, path prefix and method are ignored in that case. But I think your suggestion makes sense.

[rljonesau]

As way of my usage explanation, I have a couple of special paths for special functions that initiate a form POST in return, so an initial GET of the path gets the HTML / form to complete, then the submit throws back to the same path as a POST. Having the single Node to handle the GET and POST just makes it tidier when setting up the nodes, and more cohesive as a whole. I have been trying the change out today, and it appears to do what I need to do. I don't think there is a down side, but obviously the handler code should be programmed to ensure it is a GET or POST it is dealing with. Cheers, Ray

…

On Tue, Apr 21, 2020 at 3:45 PM Frank Hessel ***@***.***> wrote: The REST-API example defines such a node, but uses it as *default node*, meaning it's the fallback if no other node matches: ResourceNode * spiffsNode = new ResourceNode("", "", &handleSPIFFS); secureServer->setDefaultNode(spiffsNode); As the main reason for having such a default node is to handle non-matching requests, path prefix and method are ignored in that case. But I think your suggestion makes sense. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#86 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG6NZGOCECS7BZJO6X46U5LRNUXI5ANCNFSM4MM4GMAA> .