Pages WebDAV export produces 0-byte file, no warning (iPad)
| Originator: | wiml | ||
| Number: | rdar://10646348 | Date Originated: | 04-Jan-2012 06:49 PM |
| Status: | Open | Resolved: | |
| Product: | iWork | Product Version: | |
| Classification: | Crash/Hang/Data Loss | Reproducible: | Always |
04-Jan-2012 06:49 PM W Lewis:
Summary:
Pages will silently truncate the user's document if uploading to a WebDAV server that issues a redirect. Pages is able to "sign in" and to browse the DAV server without any problems, but if you upload a file to the DAV server, Pages will upload a 0-byte file (and claim success).
Steps to Reproduce:
The easiest way to reproduce this is to set up Apache with vhosts on two ports, one of which offers DAV service and the other of which always redirects to the first. (It doesn't seem to matter whether the redirect is a 302 or 307.) Pages' conversation with the web server will look like this (assuming DAV is on port 8081 and the redirect is on port 8082; examine this using Apache's logging and a packet-capture tool such as tcpflow):
--> PROPFIND http://example.com:8082/somedir/
<-- 307, redirect to http://example.com:8081/somedir/
--> PROPFIND http://example.com:8081/somedir/
<-- 207, propfind results
--> PUT http://example.com:8082/somedir/Document.pages
--> and a 1-byte dummy payload (?!?)
<-- 307, redirect to http://example.com:8081/somedir/Document.pages
--> PUT http://example.com:8081/somedir/Document.pages
--> and a 0-byte payload (?!!)
<-- 201, document created
--> PUT http://example.com:8082/somedir/Document.pages
--> and all of the document data
<-- 307, redirect to http://example.com:8081/somedir/Document.pages
--> PUT http://example.com:8081/somedir/Document.pages
--> and a 0-byte payload (!!!)
<-- 204, no content (already-empty document replaced with new 0-byte payload)
This reveals a handful of problems in Pages' DAV implementation:
1. When it follows a redirect for PUT, the second PUT is performed with a 0-byte body. If it performs the second PUT, it should include the document in the body.
2. It follows redirects for PUTs: perhaps it shouldn't (see RFC2626 10.3.8 and 10.3.3)
3. It does not interpret the PROPFIND response. Among other things, the PROPFIND informs the DAV client of the canonical names of resources, in this case of the collection that Pages is planning to PUT the document into. See RFC4918 5.2 and 9.1. If Pages interpreted the redirect+PROPFIND, then it would not have to follow any redirects for PUT.
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!