-
-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
URLs not correctly parsed for ^1.0.0 with express #82
Comments
Hey, this is intentional – see #11, #20, #21 Your It actually gets trickier than that too, because the same character can be encoded in different ways depending on the HTTP client (see #11 (comment)), which means that decoding has to happen at the server in order to normalize the request path. Hopefully that helps~! Closing, but please feel free to reply if I misread or got something wrong. |
Just to clarify: |
If coming from Express, yes, since |
Understood, thank you. Cheers! |
Or would it be possible to introduce a sirv flag that forces decoding even if req.path is defined already? Because I just noticed that I cannot manipulate req.path myself (readonly) to circumvent this... |
There won't be a config, sorry. Customization is through the This isn't a Sapper issue either. It's only because you've named your file(s) in a non-standard way that you've run into this problem. express()
.use((req, res, next) => {
req.path = decodeURIComponent(req.path);
next();
})
// ...
.use(
compression({ threshold: 0 }),
sirv('static', { dev }),
sapper.middleware()
) |
Thanks for your advice, I understand. But what you suggested does not work since I got it to work by wrapping the sirv call in another middleware though: express()
.use(
compression({ threshold: 0 }),
(req, res, next) => {
sirv("static", { dev }).call(
null,
{ ...req, path: decodeURIComponent(req.path) },
res,
next
);
},
sapper.middleware()
) So just one last question? Do you see any problem with this? To my knowledge the If not, I will suggest this approach for sapper users who want to use express. |
Yes, that's fine. It's not pretty, but IMO it's what you should be forced to do to accommodate your non-standard file names. My above example can be changed to this (I forgot express()
.use((req, res, next) => {
req.url = decodeURIComponent(req.url);
next();
})
// ... |
Info for others dealing with this: The above code does not work either, only my snippet helped in my case so far. |
Ran locally, this works with the const express = require('express');
const sirv = require('sirv');
express()
.use((req, res, next) => {
req.url = decodeURIComponent(req.url);
if (req._parsedUrl) {
var nxt = decodeURIComponent(req._parsedUrl.pathname);
req._parsedUrl.path = req._parsedUrl.pathname = nxt;
req._parsedUrl._raw = req.url;
}
next();
})
.use(
sirv('static', { dev: true })
)
.listen(3000) Have to trick FWIW, Express calls |
I do think this is a bug in |
Solved by the Polka PR and a7bd672 The Now that the latest This combo-check is backwards compatible for |
Just a short heads-up: Using the current sapper setup URLs containing spaces (%20) stopped working in conjunction with express when I updated to 1.0.0. Sirv gives me a 404 if I try to access any such URL (I don't know if this extends to other special characters, too).
For repro, I am using express@4.17.1.
I am sorry if this is a problem with express but I did some testing and I think chore(sirv): bump “@polka/url” for better decoding introduced the problem. (Might as well be an issue with @polka/url 🤔 )
The text was updated successfully, but these errors were encountered: