deps: encodeurl@~2.0.0 #5569
deps: encodeurl@~2.0.0 #5569
Conversation
|
Im gonna hack on a specific test to see if I can break it, but Im for this. Edit: wasnt able to fail the one I was interested in after hacking around |
There was a problem hiding this comment.
im happy with this as a better mitigation
We know this may break some folks, but mostly folks who were relying on invalid URLs to begin with. They can still definitely URLEncode their URLs first if they really rely on having \ converted to %5C
But semantically, those are two different URLs, so they would have been relying on a very quirky behavior. It makes other users safer, and so this a risk Im willing to accept.
|
We didn't talk about this at the @expressjs/express-tc meeting, but I am still down with this change and cutting a new release for it. |
|
@jonchurch would you want to run this release? I was in london last week and so didn't want to do it without the right attention given and haven't had a chance yet to follow up on it. Also, I was hoping we would rotate the job of running releases so if you wanted to run this I am happy to help. |
|
Im down for it, had a packed week so opted outside instead of releasing! I went to go do it over the weekend but noticed appveyor is sleeping, so I stopped and tried to rewrite our windows testing. Hence #5599, but that needs more work. AKA didn't want to merge without seeing green even though we should be G2G on this change w/r/t windows. Don't let me block though, happy to see this get out ASAP. |
|
This will also resolve #5602. |
blakeembrey
force-pushed
the
be/bump-encodeurl
branch
from
eff8596
to
d6e6204
Compare
Preferably minor, it can be bundled with #5603, which is also a minor version bump. |
|
this has consensus and patina, merging |
This should be an improved and more flexible fix over 0b74695. No more parsing required, but it does change the encoding behavior of 3 characters (
\,|,^). They will no longer be encoded. I'm considering this a continuation of the bug fix, although it introduces a potential breaking change for any one that might have been relying on\to be encoded in the location header without having encoding it themselves. I believe the impact should be negligible to non-existent, but it's not possible to confirm before landing this fix.This fix is preferred over the existing patch in master because it'll better handle all alternative formats of URLs and encode them consistently.