Add an on() function to ESP8266 Webserver that supports startsWith

[bmuessig]

Hello!

Having a way to pass paramters via URL seems like a very important thing to have and I think a on() handler that uses startsWith should therefore be added.
As this was essential in one of my projects, I did the changes to my local copy of the esp8266webserver library but I really strongly suggest adding this feature to allow for more interactive websites and easier programming of things like: http://esp8266.local/configure/mdns_name/this_is_my_new_name and similar use cases like passing strings via the url.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[bmuessig]

Well it isn't supposed to be a real link but an example of what I am using
the new functions for.

2016-05-11 21:26 GMT+02:00 Robert [email protected]:

link does not work.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#2019 (comment)

[Duality4Y]

yes i know now :) didn't read it right. pretty nice function to have.

[randuhmm]

I have some experimental code that makes it possible to create a RequestHandler object that can handle URI path parameters. The basic usage is to create a handler object like this:

void myHandler(LinkedList<String>& segments) {
    // Handle the request and path parameters here
}

PathSegmentRequestHandler* handler = new PathSegmentRequestHandler(
    myHandler,
    "/my/path/widgets/{}/things/{}",
    HTTP_ANY);
http.addHandler(handler);

The PathSegmentRequestHandler is a custom class that I created that is able to parse individual segments of the URI and extract any parameters. The {} acts as a placeholder for the parameter.

While this is working for me, I think there is some room for optimization so that the path segments do not need to be parsed individually by each handler. I think that the server should first check all of the static paths for matches and then, if no match is found, the URI can be separated into segments and the dynamic paths can be checked.

[nardev]

Would be nice and cleaner to be able to aloate function only for serving files per path preferences...

like

[ip]/scripts/{something_goes_here}

to pass full uri to a handler for anything under "scripts" .. and than determine if it fulfills our criteria and what to do with it.. fetch from eprom or not... etc...

[bytemage]

Hope this will make it in the next milestone. It's sorely missing.

[devyte]

There are some VERY hairy issues being investigated that are much higher priority than this. To help, I encourage anyone who needs this to make a PR.
That goes in general for all issues, especially those that have a milestone set. If you have the time and knowhow, or want to learn through investigation and experimentation, step up. This is a community effort, after all, and we're short handed.

[devyte]

There are 3 possible solutions here, and choosing which must be done carefully, because once released and adopted by users, there's no switching later.
Option 1: proposal by @Bmooij with custom "{}" for wildcard and pathArgs in #5214
Option 2: glob style pattern matching, which is super standard and used in most shells in #5467
Option 3: regex pattern matching, which is also super standard, although a bit more complex.

Which solution to adopt requires further discussion, so pushing this back.

[liebman]

What about optionally providing a wildcard provider object? The default could be glob and this would allow flexibility for other wildcarding. Edit: the default should be whatever uses the fewest resources in operation.

[devyte]

@liebman Something along those lines did cross my mind, I.e.: have a functor provide the match functionality, like a policy class. However, RequestHandlerImpl must be kept in mind.
Requires discussion and thought, maybe some code redesign, so not for 2.5.0, which is imminent.

[devyte]

There are several proposals here, and they require evaluation (e.g.: bin size).
Pushing back.

[bmuessig]

There are 3 possible solutions here, and choosing which must be done carefully, because once released and adopted by users, there's no switching later.
Option 1: proposal by @Bmooij with custom "{}" for wildcard and pathArgs in #5214
Option 2: glob style pattern matching, which is super standard and used in most shells in #5467
Option 3: regex pattern matching, which is also super standard, although a bit more complex.

Which solution to adopt requires further discussion, so pushing this back.

I generally like the Regex idea, but it might be a bad idea in an embedded context, as Regex parsers usually are not that small in binary size. But considering some targets have enough code space to fit a Regex parser without impacting the code footprint significantly, I second that idea.

[devyte]

@bmuessig PR #6696 does all 3 cases,but it still needs to be confirmed/tested/etc. In theory the regex does increase bin size, although only when you actually use it. If you don't and use e. g. glob instead, then the bin shouldn't increase. That's the idea, anyways.

[devyte]

#6696 is merged, closing.