in directory, fix the listing of subdirs that reside in a subdirs that have spaces - #1253
Conversation
There was a problem hiding this comment.
decodeURI can throw... decodeURI('%f')
There was a problem hiding this comment.
@hueniverse, so here I'm a bit confused.
Is it possible to request a not encoded url? yes (at least with the basic http module as server & curl it is possible)
is it allowed? isn't it a bad request? for example, is GET /dir/%/ allowed as a good request? shouldn't it be GET /dir/%25/ ?
It's also harder to test this scenario, since the hapi router.match doesn't match it (at least from what I see, I will dig a bit deeper).
There was a problem hiding this comment.
@hueniverse, so I found out that route is actually decoding url component using these functions:
internals.setParam = function (name, value, params, paramsArray, isEmptyOk) {
var isValid = (isEmptyOk || value);
if (isValid &&
params) {
var decoded = internals.decodeURIComponent(value || '');
if (decoded === null) {
isValid = false;
}
else {
params[name] = decoded;
paramsArray.push(decoded);
}
}
return isValid;
};
internals.decodeURIComponent = function (value) {
try {
return decodeURIComponent(value);
}
catch (err) {
return null;
}
};
which ultimately means- a path that is not decoded correctly is invalid. However, note that it will return 404, and it will try to decode it foreach route.
in directory, fix the listing of subdirs that reside in a subdirs that have spaces
in directory, fix the listing of subdirs that reside in a subdirs that have spaces
there was a problem with listing a subdir that is within a subdir with spaces (for example
GET /directory/some%20dir/subdir) because it was actually encoded twice.at the beginning I thought I might change
pathEncodeimplementation to something like:but I guess the resource was the one causing the issue.
I also replacedencodeURIComponentwithencodeURI- if it is necessary we should have a test that captures it.encoding twice:
update: I reverted to encodeURIComponent, and I found out that route already decodes the url parameters, so decoding the path parameter may not throw