Description of problem: Can't save to WebDAV location Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Set up WebDAV (with Apache) 2. Put an ODT document at a WebDAV location 3. Open the document with OpenOffice.org (first change the UI to use OpenOffice.org file dialogs) 4. change stuff in the document 5. save the document Actual results: OpenOffice.org can't save the document. Expected results: OpenOffice.org should save the document. Additional info: This bug can only be reproduced on Fedora 10. I've researched it with builds from OpenOffice.org 3 from OpenOffice.org itself on Linux and Windows Vista, but could not reproduce it. It is documented in the OOo bugzilla: http://qa.openoffice.org/issues/show_bug.cgi?id=94354
Possibly related to bug 479199 or an issue which will be addressed in the next F-10 update. Though davs:// https:// http:// and dav:// urls should all use the in-built handler, so this might be different.
It might be. It would explain why I am not seeing any PUT requests at all when using the OOo3 build in Fedora 10.
Do you think you could check the latest testing update of openoffice.org-3.0.1-15.1, which has at least one known issue which might affect this. e.g. yum upgrade openoffice.org-writer --enablerepo updates-testing If the problem persists, then can you give me the exact route to accessing the webdav share. Do you mount it with nautilus first, i.e. from places->connect to server, and then open the document from a nautilus window, or from the gtk file dialog.
It doesn't work. What I do is: * enable OOo file dialogs * open https://route/to/webdav/location/file It opens just fine and I can read and edit, but saving does not work. This does not happen with the build directly from OOo.org. One thing is that I do not see any traffic at all between the webserver and the client machine at all when pressing 'save'. I will do some strace debugging tomorrow.
Personally I can save *once* to a location, but not a second time. e.g. oowriter dav://path/to/a/location.odt enter username and password edit save (all ok) edit some moew save authentication failure
Got it, at least I got the initially reported problem. Our neon reports "DAV:Collection" for a folder not "Collection" like the code expects. Vanilla comes with an older neon, so it works there but not here. will be in >= 3.0.1-15.2
Just for reference: http://www.openoffice.org/issues/show_bug.cgi?id=98288 It is a bad, ehm, disturbing to see that they use string comparisons to deal with XML data, instead of using proper XML parsing. What if I'd change my namespace in my server to something else? It's a fix, but I'm not sure it is the proper fix.
Re: "Just for reference" I know, I filed that patch just now. cmc is my openoffice.org dev accountname
I already figured that out :-) Thank you for fixing this particular instance. However, I am wondering what would happen if I would have yet another different namespace (I don't know how Apple does this with their webdisk stuff for example), or if I would have a tag <collectionblaah>. In my honest opinion this should be done using XML parsing, not by string comparisons. Should I file another bug for this?
The string changes depending on the version of neon used, so (without looking into the implementation admittedly) the string looks like an artefact of neon itself. Also the string is <DAV:Collection></DAV:COllection> rather that e.g. <DAV:Collection/> so I suspect that dragging a full-blown XML parser into the equation won't gain a whole pile. If there's a concrete example of a problem, then sure, but there's a load of other more pressing problems in that webdav backend (e.g. use dav:// instead of http:// and only the first save will work, not the second) that need addressing
openoffice.org-3.0.1-15.2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
I just tested it, it seems to work. There are a few other oddities, which seem unrelated to this bug. Thanks!