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 [email protected] 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 https://github.com/fhessel/esp32_https_server/issues/86#issuecomment-616965662, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG6NZGOCECS7BZJO6X46U5LRNUXI5ANCNFSM4MM4GMAA .