Wildcards strip the first character from `req.url` about tinyhttp

[aarontravass]

Thanks for reporting this issue. The bug is caused due to the way the req.url property is set when a * is present

tinyhttp/packages/app/src/app.ts

Line 368 in ed51d60

req.url = lead(req.url.substring(path.length))

A PR is welcome

[adhusson]

I'll look at making a PR but I'm not sure about 2 things:

• When the path is /foo/:pat and the url is /foo/bar is it expected that req.url becomes / (I would have expected the URL to remain unchanged)?
• When the path is /foo/* and the url is /foo/bar should req.url become /foo or /foo/bar or /bar?

[aarontravass]

When the path is /foo/:pat and the url is /foo/bar is it expected that req.url becomes / (I would have expected the URL to remain unchanged)?

As per express, req.url is /foo/bar when the path is /foo/:param

When the path is /foo/* and the url is /foo/bar should req.url become /foo or /foo/bar or /bar?

Since the aim is to offer similar APIs to express, req.url should output /foo/bar.

[aarontravass]

Here's the express code

import express from 'express'

const app = express()

app.get('/foo/:path',(req,res) => {
  console.log(req.url, req.params);
  res.send(`@${req.url}`);
});

app.get('/hello/*',(req,res) => {
  console.log(req.url, req.params);
  res.send(`@${req.url}`);
});

app.listen(3000);

[talentlessguy]

Thanks for reporting - seems like a very simple bugfix - PR is welcome as said above

[adhusson]

@aarontravass What you descibe as express's spec is not what I observe with tinyhttp:

// shows @/ on /x/bar
app.get('/x/:y',(req,res) => {
  res.send(`@${req.url}`);
});

This is probably a different issue from the one I mentioned above, which I'm reproducing here:

// shows @/ar on /foo/bar
app.get('/foo/*',(req,res) => {
  res.send(`@${req.url}`);
});

Finally I'm seeing a similar but maybe unrelated behavior:

let urls = [];
const router = (req,res,next) => {
  urls.push(req.url);
  next();
}

// shows @/bar @/ar @/ on /z/bar
app.use('/z',router,router,router,(req,res) => {
  res.send(`@${urls.join(' @')}`);
  urls = [];
});

I'm guessing all of the above needs to be fixed but I'm waiting to get your input on that.

[aarontravass]

Looks like the code for req.url when a param is present is broken as well. The buggy line is

tinyhttp/packages/app/src/app.ts

Line 365 in ed51d60

const url = req.url.slice(req.url.indexOf(first) + first?.length)

Finally I'm seeing a similar but maybe unrelated behavior:

This issue is caused by modifying the original request object. Essentially, Line 368, as mentioned by your original post, keeps stripping the first character and it does so for all middle wares. Good catch!

[adhusson]

I could use some help navigating the code. I don't understand how handle, as it is today, differentiates between a route (app.get, etc) and a middleware (app.use). Intuitively:

• Within a route, the URL should be left as-is, with no modifications (except removing the query string).
• Within a middleware, the URL should be stripped of its path.

Replacing the current logic with the logic I describe above is quite a big change so I'd like to check with you that it makes sense:

• The current logic including checking for includes(':') and stripping the url of the path should be removed.
• It should be replaced by the logic above.

Is this right?

[aarontravass]

I don't understand how handle, as it is today, differentiates between a route (app.get, etc) and a middleware (app.use).

There is not much difference between a route and a middleware. In fact, if you look at packages/router/src/index.ts, you'll find that routes are pretty much similar to middlwares.

tinyhttp/packages/router/src/index.ts

Line 202 in 585633f

this[m.toLowerCase()] = this.add(m as Method)

The only difference is that routes are 'mounted' on the app itself and hence, do not need an extra path variable (also called fullPath in the code) while middlwares do. This is due to the fact that you can mount middlewares such as subapps onto a specific path.

Replacing the current logic with the logic I describe above is quite a big change so I'd like to check with you that it makes sense:

Yes, your idea is correct.

[aarontravass]

Replacing the current logic with the logic I describe above is quite a big change so I'd like to check with you that it makes sense:

I believe the fix should be pretty simple since all you need to do is differentiate correctly between a route and a middlware.