Skip to content
This repository has been archived by the owner on Jan 18, 2021. It is now read-only.

PROPPATCH mangles XML values #203

Closed
PVince81 opened this issue May 14, 2020 · 9 comments · Fixed by cs3org/reva#743
Closed

PROPPATCH mangles XML values #203

PVince81 opened this issue May 14, 2020 · 9 comments · Fixed by cs3org/reva#743
Assignees
Labels
bug Something isn't working

Comments

@PVince81
Copy link
Contributor

Matches the "propwformed" Litmus test from the "props" suite: #183

Steps to reproduce

  1. Create a folder "test"
  2. Create a local file "proppatch.xml" for setting an XML value
    <?xml version="1.0" encoding="utf-8"?>
    <D:propertyupdate xmlns:D="DAV:">
      <D:set><D:prop><t:valnspace xmlns:t="http://example.com/test"><foo xmlns='http://bar'/></t:valnspace></D:prop></D:set>
    </D:propertyupdate>
  3. Run curl:
    % curl -s -k \     
       -u einstein:relativity \
       -X PROPPATCH \
       -H "Content-Type: text/xml" \
       --data-binary "@proppatch.xml" \
       "http://localhost:9140/remote.php/webdav/test"
  4. Then go into "/var/tmp/reva/data/einstein/files" (or wherever the data files are)
  5. getfattr -d temp

Expected result

% getfattr -d test
# file: test
user.oc.id=0s4kQ7O0r3TWqERtgNkfTznA==
user.oc.md.http://example.com/test/valnspace="<foo xmlns=\"http://bar\" />"

Actual result

The XML element is mangled, the xmlns property is duplicated, resulting in a badly formed XML structure:

% getfattr -d test
# file: test
user.oc.id=0s4kQ7O0r3TWqERtgNkfTznA==
user.oc.md.http://example.com/test/valnspace="<foo xmlns=\"http://bar\" xmlns=\"http://bar\"></foo>"

Version

reva 4621a5d3c79e2371a42d7a0d306962bf380db8d1

@PVince81 PVince81 added the bug Something isn't working label May 14, 2020
@PVince81 PVince81 self-assigned this May 14, 2020
@PVince81
Copy link
Contributor Author

I've added logging in Reva to see the value of "InnerXML", apparently it's been decoded wrong:

2020-05-14T14:40:28+02:00 DBG Preparing property key=http://example.com/test/valnspace pkg=rhttp service=reva traceid=971a5ad346a52f32c641f3d1e25eaf8f value="<foo xmlns=\"http://bar\" xmlns=\"http://bar\"></foo>"

Interestingly, if I change the input to be "xxmlns" then it doesn't get duplicated.
So maybe the decoder has trouble with the "xmlns" attribute or namespaces in general.

@PVince81
Copy link
Contributor Author

If I set <D:set><D:prop><t:valnspace xmlns:t="http://example.com/test"><f:foo xmlns:f="http://bar"/></t:valnspace></D:prop></D:set> as input, the parsed value gets even more ridiculous:
<foo xmlns="http://bar" xmlns:_xmlns="xmlns" _xmlns:f="http://bar">

@PVince81
Copy link
Contributor Author

as far as I understand, this is the bit that tells the parser to not parse the contents of the element and reuse it as is: https://github.com/cs3org/reva/blob/master/internal/http/services/owncloud/ocdav/propfind.go#L547

still, for some reason, it seems to insist on parsing it and mangling it

@PVince81
Copy link
Contributor Author

might be a bug in the decode, I didn't find which one yet: golang/go#13400

maybe it's another yet undiscovered bug

@PVince81
Copy link
Contributor Author

my local go version where I run Litmus tests is go1.13.10
I'll try with go1.14 in case the bug is fixed there...

@PVince81
Copy link
Contributor Author

problem also happens with go1.14.2

@PVince81
Copy link
Contributor Author

@PVince81
Copy link
Contributor Author

I see those seem to be there for handling the "lang" attribute, so apparently it's not enough to just keep everything as is ?

http://www.webdav.org/specs/rfc4918.xml#ELEMENT_set

spec for property values: http://www.webdav.org/specs/rfc4918.html#property_values

@PVince81
Copy link
Contributor Author

ok, seems I managed to fix the custom UnmarshalXML to work on the parent element: cs3org/reva#743

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant