Strange encoding problem with certain content type settings?

, ,
1

Hi

I’m using Tamino WebDAV Server 3.1.4, with DeltaV enabled.

I had a particular document with Unicode characters 2013 and 2019. One way or another I managed to save the document to Tamino with those characters represented as something else.

Now the problem is, if i open this document in XML Spy, save it via webDAV, and reload it in XML Spy, the number of strange characters doubles, and doubles again everytime I repeat this sequence!!! This resource has <D:getcontenttype> set to application/octet-stream

However, if i PUT it with some other name, i am then not able to reproduce this behaviour. I think this is because XML Spy puts the new file with <D:getcontenttype> set to text/xml, which Tamino appears to handle differently.

My theory is that this problem only occurs if <D:getcontenttype> is set to application/octet-stream OR application/xml, rather than text/xml.

Does this make sense based on what Tamino does internally?

thanks

Jason

2

I’ve verified the problem behaviour and now attach a test case.

1. Unzip the attached file. It contains a short xml doc called test.xsl. If you open it in a UFT-8 aware editor, you’ll see a couple of unicode characters in it - a dash and an apostrophe.

2. Use a WebDAV client to put this file to Tamino.

If you PUT it with content type text/xml, you can GET it again with eg XML Spy, and the content is correct.

If you GET it with the Tamino WebDAV Basic client, you’ll see the bytes:
the dash - e2 80 93
he apos - e2 80 99

If you PUT it with content type application/xml, or application/octet-stream,
and GET it with XML Spy, you’ll see strange characters in place of the dash and apos.

If you GET it with the Tamino WebDAV Basic client, you’ll see the bytes:
the dash - c3 a2 c2 80 c2 93
he apos - c3 a2 c2 80 c2 99

So, the conclusion appears to be that the file gets corrupted by Tamino unless the WebDAV client sets the content type to text/xml !
test.zip (253 Bytes)

3

Just tested this with Tamino 4.1.1.1 and TWS 4.1.1, and happily, with those versions, the content is returned correctly with each of the three content types I tested.