ocdav: Fix parsing of PROPPATCH XML properties #743
Conversation
PVince81
changed the title
|
very strange, the linter says this is unused but it is used... I can't remove it without causing compilation errors: |
Use the parent struct when parsing to make sure the decoder finds the hint about "innerxml" parsing mode for proppatch properties, and prevents mangling of said values when they contain an "xmlns" attribute.
|
ok, got it, it's the whole type/struct/class that is unused (me still learning Golang...) |
There was a problem hiding this comment.
AFAIU the previous code tried to deal with cases where the proppatch value was reusing an existing namespace from outside the innerxml. I think it makes more sense to treat it as an opaque value. Maybe the existing code tries to do a little too much magic. Getting rid of it is a win.
strange, I seemed to remember seeing a comment somewhere that said that it's anyway illegal to reuse namespaces from the parent but cannot find it anywhere in the spec (not present in http://www.webdav.org/specs/rfc4918.html#property_values) in any case, I think there isn't much benefit in supporting this as the custom properties we'll be setting will have their own namespaces. And for known properties (like the DAV: ones) they have no complex XML values. I'm not even sure whether Sabre DAV's XML supports this scenario of namespace reuse. |
Use the parent struct when parsing to make sure the decoder finds the
hint about "innerxml" parsing mode for proppatch properties,
and prevents mangling of said values when they contain an "xmlns"
attribute.
Fixes owncloud/ocis-reva#203
@butonic please double check the fix as I didn't understand the lang-related code and seemingly could not create a test case that has any difference before and after the fix.
If I proppatch a value of
<foo xml:lang="en" xmlns="http://bar"/>it will now also appear as<foo xml:lang="en" xmlns="http://bar"/>in the extended attribute and propfind result.