Skip to content

Conversation

@rodcoffani
Copy link
Contributor

@rodcoffani rodcoffani commented Dec 19, 2025

Some parts of this PR are a workaround while there isn't a fix in EOS for path encoding.
These can be reverted once there is one.
There is still a known issue with the character % (which should also be solved with the fix)

  • fix PROPFIND response when listing a folder named with special charactrers
  • enable the creation of files inside this folder
  • enable to open files located inside this folder (to be fixed in the web)

@update-docs

This comment was marked as resolved.

@rodcoffani rodcoffani force-pushed the fix/special-characters branch from b0effcf to cc9f253 Compare January 7, 2026 09:20
@rodcoffani rodcoffani force-pushed the fix/special-characters branch 2 times, most recently from 35ff8ec to e7e657e Compare January 20, 2026 16:26
@rodcoffani rodcoffani force-pushed the fix/special-characters branch from e7e657e to 95e6938 Compare January 21, 2026 14:45
@rodcoffani rodcoffani marked this pull request as ready for review January 21, 2026 14:47
@rodcoffani rodcoffani force-pushed the fix/special-characters branch from 95e6938 to a0f9a30 Compare January 22, 2026 10:23
@rodcoffani rodcoffani force-pushed the fix/special-characters branch from a0f9a30 to 5df898e Compare January 22, 2026 10:35
log.Error().Str("func", "PUTFile").Str("url", finalurl).Str("err", err.Error()).Msg("can't get a new location for a redirection")
return err
}
// FIXME: remove once the URL from 'Location' is properly encoded (with EOS 5.4)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so can we remove this now, since the fix is in homedev?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it depends on how fast the new version of eos is going to production, my suggestion would be to merge this and add the removal to the eos5.4 branch

encodedParentPath := url.PathEscape(parent.Path)
encodedMdPath := url.PathEscape(md.Path)
encodedRelativePath := strings.TrimPrefix(encodedMdPath, encodedParentPath)
_, err = url.PathUnescape(encodedRelativePath)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's the point of doing this if you don't use the result?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to check if the URL is still valid after these operations, splitting the unescaping the encodedRelativePath and href in two separate lines.
this intends to have a more precise error message instead of doing all the operations in the same line.
but it shouldn't be a problem to remove this and deal only with the href, err = url.PathUnescape(href) later.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that might be a bit cleaner, in principle it works anyway so we should never see those messages, and if this ever needs to be debugged because something breaks they can just split the steps then

return nil, errors.Wrapf(err, "failed to calculate path relative to parent: %v", md.Path)
}
href, err = url.JoinPath(hrefBase, relativePath)
href = url.PathEscape(hrefBase) + encodedRelativePath
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@jessegeens jessegeens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants