Bug 480057
Summary: | Can't save documents to WebDAV with OpenOffice.org 3 in Fedora 10 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Armijn Hemel <armijn> |
Component: | openoffice.org | Assignee: | Caolan McNamara <caolanm> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | caolanm, jnavrati |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-01-29 23:10:39 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Armijn Hemel
2009-01-14 19:31:50 UTC
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! |