basic_streaming transfer adapter handling of 'filename' URL parameter #92
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
'filter' the 'filename' URL parameter through 'safe_filename' IF it was actually sent with the request
It seems this URL parameter is not always passed by clients.
Out of my two setups, the windows based one does not, which led me to investigate.
git version 2.31.1.windows.1 using ssh to clone a repository with lfs.url=http://... - URL parameter not passed, hitting the failure mode mitigated by this PR
git version 2.31.1 using a local file path to clone a repository with lfs.url=http://... - Everything is fine
I have not investigated yet whether the URL parameter passing differences are by design or by accident, however it seems prudent for the transfer adapter to cleanly handle this case.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
'filter' the 'filename' URL parameter through 'safe_filename' IF it was actually sent with the request
It seems this URL parameter is not always passed by clients.
Out of my two setups, the windows based one does not, which led me to investigate.
git version 2.31.1.windows.1 using ssh to clone a repository with lfs.url=http://... - URL parameter not passed, hitting the failure mode mitigated by this PR
git version 2.31.1 using a local file path to clone a repository with lfs.url=http://... - Everything is fine
I have not investigated yet whether the URL parameter passing differences are by design or by accident, however it seems prudent for the transfer adapter to cleanly handle this case.