Request path in req.uri does not match full path of request for nested servers.

[dcow]

I understand this may be by design due to the nature of nesting, etc. If so, then the issue is that for an application that implements something like signed requests, the full path of the incoming request needs to be known by the middleware so that it can generate the right digest. I tried querying req.param("--tide-path-rest") but it returns the same data as req.uri().path() even though there's an entry in the map that shows more of the path.

[dcow]

This is due to using nest instead of all. However, when using all tide doesn't want to resolve any of my routes anymore.

[jasontheiler]

I'd also really like to know if this is by design or not. And if so, how do you get the full request path then? It's really annoying when you try to do some URL generation using req.url().join("...") inside a nested middleware or endpoint.

[Fishrock123]

This sounds like a bug but I think it may be tricky to fix.

[dcow]

@Fishrock123 I may have some time to look into fixing this. What is tricky about the issue, in your opinion? And what should the correct behavior be? Should nested middleware req.uri contain the full path? Or should a public param be added that contains the original req uri? Or is all broken?

[Fishrock123]

@jbr would routefinder help this? I think so, right?

[jbr]

I'm not entirely sure, but I don't think so. I think this is a tide design issue, where it's intended that the request url is rewritten inside of nested apps, but there isn't an alternative api for the inner app to find out the actual full url. In my opinion, there should be two distinct apis: One is "what's my relative path from my mount point, which I might not know as a nested app author" and the other is "what is the full request path, untouched"

[Fishrock123]

I agree with that, yeah.

[sorcix]

I'm working around this problem by using the Route::at method.

let mut server = tide::new();
server.at("/foo").get(foo_handler);

// "nested" server
let mut api = server.at("/api");
api.with(auth).with(cors).with(JsonApi);

api.at("/endpoint1").get(something);
api.at("/endpoint2").get(somethingelse);

It seems to behave as I expected a nested server to behave.

[dcow]

When I do this the application crashes for reasons I can’t discern. I’ll give it another shot and report back.

[sorcix]

I've found a single difference between nested servers and this workaround with routes since I've started using it: the moment at which middleware is executed.

Middleware on a Server seems to execute before the routing, so my auth middleware returns 403 for unauthenticated requests even when the requested route does not exist. When using this workaround middleware only executes for routes that do exist, as they are set on the routes themselves.

In the example for my previous post:

let mut api = server.at("/api");
api.with(auth).with(cors).with(JsonApi);

api.at("/endpoint1").get(something);

This means that /api/endpoint returns 403 but /api/bar or /api/endpoint/foo returns 404. When using a nested server they would all return 403.

But it works for now. :-)