URI decode path parts #51
Conversation
|
Yeah, I think this makes sense. I'd be curious to know if there was any major performance impact by doing this, but I'd imagine it's probably minimal if anything. |
|
yikes... 😶 I can see how this would be helpful. Do you have any ideas on how we can cut that time down? We could also merge this as is if there's savings somewhere else in this shard. |
|
Woah, thank you for catching that. Definitely something I missed checking. Leave it with me and I’ll see what I can do! |
|
That should be a little less intense now. As it peels off the path segments, it will only pipe those containing encoded chars through Currently this happens strictly for the full path. There's potentially some additional gain possible by reading these segments lazily as the matcher walks the tree, but implementation of that requires a bit of modification to other areas of this lib and would introduce a fair bit of noise to the intent of this PR. Thanks again for keeping an eye perf. |
|
wow! This even seems to speed it up a bit! 🥳 |
This PR introduces percent-decoding for information contained within path parts.
This ensures that all paths are normalised as per https://datatracker.ietf.org/doc/html/rfc3986#section-7.3 at the first valid opportunity.
Driving reason for this is to prevent the need for explicit decoding within Spider Gazelle's action-controller (which uses this) and could be placed there. This just appears to be the neat point to solve this more generally. If you feel that's a better spot, please do feel free to close this.