Conversation
Before the move to the viewer the URL of the PDF file to load was got using "Files.getDownloadUrl()", which encodes each section of the path as a URI component. The full URL, in turn, was again encoded as a URI component to set the source of the iframe in which the PDF viewer is loaded. When the PDF viewer parsed the URL it decoded it once, so each section of the path was still encoded as a URI component. After the move to the viewer the URL of the PDF file to load was got from the "davPath" property set by the viewer, which uses the filename as is. The full URL was then encoded as a URI component, so when the PDF viewer parsed and decoded the URL the raw filename was used. In most cases it worked fine, but if the filename included some special character, like "?", the file failed to load. Now, instead of using the "davPath" property set by the viewer, each section of the dav path is encoded as a URI component. The encoding tries to not make any assumption on the format used by the viewer to avoid being coupled too much. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Member
Author
|
/backport to stable20 |
skjnldsv
reviewed
Jan 22, 2021
Comment on lines
+40
to
+61
| encodedDavPath() { | ||
| const hasScheme = this.davPath.indexOf('://') !== -1 | ||
|
|
||
| const pathSections = this.davPath.split('/') | ||
|
|
||
| // Ignore scheme and domain in the loop (note that the scheme | ||
| // delimiter, "//", creates an empty section when split by "/"). | ||
| const initialSection = hasScheme ? 3 : 0 | ||
|
|
||
| let encodedDavPath = '' | ||
| for (let i = initialSection; i < pathSections.length; i++) { | ||
| if (pathSections[i] !== '') { | ||
| encodedDavPath += '/' + encodeURIComponent(pathSections[i]) | ||
| } | ||
| } | ||
|
|
||
| if (hasScheme) { | ||
| encodedDavPath = pathSections[0] + '//' + pathSections[2] + encodedDavPath | ||
| } | ||
|
|
||
| return encodedDavPath | ||
| }, |
Member
There was a problem hiding this comment.
The question is: shouldn't this be on Viewer? we have the same issue for other files
Member
Author
There was a problem hiding this comment.
Yes, that question is in the pull request description...
Member
|
SO go or no go? |
Member
Author
|
I would say merge now and then adjust later if it is fixed in the viewer instead of the PDF viewer. Otherwise Nextcloud 21 could end shipping with the issue. |
delete-merged-branch
bot
deleted the
fix-opening-pdf-files-with-special-characters-in-their-name
branch
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Before the move to the viewer the URL of the PDF file to load was got (indirectly) using
Files.getDownloadUrl(), which encodes each section of the path as a URI component. The full URL, in turn, was again encoded as a URI component to set the source of the iframe in which the PDF viewer is loaded. When the PDF viewer parsed the URL it decoded it once, so each section of the path was still encoded as a URI component.After the move to the viewer the URL of the PDF file to load was got from the
davPathproperty set by the viewer, which uses the filename as is. The full URL was then encoded as a URI component, so when the PDF viewer parsed and decoded the URL the raw filename was used. In most cases it worked fine, but if the filename included some special character, like?, the file failed to load.Now, instead of using the
davPathproperty set by the viewer, each section of the dav path is encoded as a URI component. The encoding tries to not make any assumption on the format used by the viewer to avoid being coupled too much.I do not know if this should be something to be fixed in the viewer instead (although images with "?" in their name load fine 🤷). However, even in that case, this should fix the PDF viewer until the changes in the viewer are ready.
How to test
test?.pdfResult with this pull request
The file is opened in the viewer.
Result without this pull request
The viewer opens, but the file fails to open.