Tide: How to route unknown paths?

[silvioprog]

Hi.

I'm trying to write a reverse proxy example (https://github.com/http-rs/tide/pull/784), but I don't know how to route all possible paths. Consider the following example:

app.at("*") ... ;

now, take a look this tests below:

curl http://localhost:8080/test
ok
curl http://localhost:8080/
404
curl http://localhost:8080
404

Well, since wildcard allows anything, it should return ok in and / too. 😕

Thank you!

[jbr]

Is tide the right tool for a reverse proxy, vs using async-h1 directly?

[silvioprog]

@jbr It will be a naive simple example just to show how a tide-based server (instance) can handle reverse proxy.

[christoth]

I'm also trying to create a simple tide+surf based reverse-proxy.

I experienced the same behaviour and while hoping for the same expected behaviour...

The work-around I used was:
app.at("/").all(move |mut client_request: Request<()>| async move { ... });
app.at("*").all(move |mut client_request: Request<()>| async move { ... });

That combination should route all your unknown paths.

[jbr]

Out of curiosity to understand this use case, do you have other routes in addition to these? If not, using tide will be slower than using async-h1 directly as a reverse proxy. If there is no reason _to_ use tide itself, we probably shouldn't include an example that doesn't use the router or other tide-specific features

[Fishrock123]

This is useful for custom 404's. We should support this.

[christoth]

Thanks for the guidance!
I'm working on an async-h1 reverse proxy example. It's pretty basic, as I'm learning Rust.

[spikecodes]

The reverse proxy example would be a great addition!

[jbr]

@spikecodes Which, a reverse proxy or * matching /?

[spikecodes]

My bad, I meant the reverse proxy example. I now see though that it's a separate PR: #784

[yoshuawuyts]

This likely needs to be fixed in route-recognizer; I've filed an issue there: https://github.com/http-rs/route-recognizer/issues/45.