Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Jetty 12 - Simplification of aliases in
PathResource
#8631Jetty 12 - Simplification of aliases in
PathResource
#8631Changes from 6 commits
97739f9
9e29c95
fcd6e56
a32aa83
db4a44c
882cdd9
a3d9efb
4d39c8a
4411d10
48eaf49
98f25cb
5fb4e65
bbc261c
79cd37d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Files.exists()
implicitly take aFOLLOW_SYMLINKS
, so the first at line 173 check should be enough.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not if the path has unresolved
..
segments, thenFiles.exists()
returns false even if it does exist.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with sbordet
If
this.path
was created with one of theURI
based methods for creating aPath
(eg:Paths.of(URI)
orPaths.get(URI)
) then your statement is true.As there is an expectation that the
URI
it is given is absolute, canonical, and normalized.But if
this.path
was created from aString
or otherPath
object, even the/../
segments have no impact on theFiles.exists()
logic and will return true.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not correct.
The following test passes and shows that Files.exists does not work with
/../
segments. And since you can createPathResource
with aPath
directly we cannot assume that the path does not contain/../
segments.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
Files.exists()
does work with/../
if each element of the path exists.In your case
foo
does not exist on your filesystem.This is part of the filesystem specific normalization techniques.
Some filesystems will find it (some will not).
Don't write your code assuming that all filesystems behave the same in this regard.
Example code (tested on Linux with ext4 filesystem)
Executing with "foo"
Executing without "foo"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the same behavior you get on linux with
ls
...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way I see it we have a few options here.
Resource
implementations do the URI normalization, removing segments like/../
before creating thePath
object.Resource
implementations honor the as-submittedURI
, with noResource
implementation normalization, and let the FileSystem suss out if the content can be referenced or not.We are doing 1 currently, but should we?
Is it such a terrible idea to reject requests for content like
dir-does-not-exist/../test.dat
and allowdir-that-exists/../test.dat
?I could easily be convinced that the
Resource
implementations should not perform URI normalization.It just means a few types of torturous requests we used to receive in the past we no longer support.
I wonder, is supporting
/dir-does-not-exist/
segments hiding or revealing extra information about the filesystem we shouldn't be doing? (need more time to ponder this)What does supporting
/dir-does-not-exist/
segments mean for ResourceCollection too? (if anything)Or, if we want to support these requests still, it means that the normalization occurs at the layer above
Resource.resolve(String)
(which kinda makes sense, and I suspect it would simplify the protected paths issues too)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename to
resolveAlias()
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @sbordet, this is a
resolveAlias()
orresolveTarget()
name.