The server I am using is configured webdav, the configuration connection is: https://support.omnigroup.com/omnipresence-os-x-server/
The prompt is to be able to connect to the server and log in to view the file.
When I modified it, I was waiting for the upload. After waiting for a long time, I was prompted to upload failed.
How does this problem occur? How to solve it?
@ongfei Custom WebDAV servers are tricky for us to help troubleshoot, but if you send an email to omniplan@omnigroup.com our Support team might be able to suggest a few things to check in your setup.
I am having the exact same problem with OmniPlan 3 on macOS as well as on iOS.
From looking at the WebDAV logfiles (it’s an apache2 server with the DAV module), I see a lot of 401 and 412 errors. At first glance it looks as if OmniPlan does not send the username/password with each request.
Unfortunately, the Omni support is not helpful at all, so far they suggested to use OmniSync server instead of helping to narrow down then problem…
Sorry for the trouble you’re having @mbalmer, and that you were disappointed in the initial response you received from our Support team! We’re working hard on your issue, but as I mentioned previously in this thread, issues with custom WebDAV setups can be really hard for us to track down. When our Support team suggested Friday that you attempt to sync with the Omni Sync Server, our express purpose was to narrow down the problem, not to propose our server as a possible production environment for you.
It’s true that OmniPlan only sends credentials when challenged by your server for them, and we could reduce round trips by proactively offering them when appropriate, however it does not look like this is the cause of your issue. Our best guess right now is there is some quirk regarding eTag support in your Apache server requirement. We’re not trying to blame Apache here, it’s more likely a nuanced server response we haven’t anticipated and haven’t coded for.
We’re working to replicate your production environment here as closely as possible to reproduce the problem. We’ll send a followup email your way asking for more information as soon as we can formulate the right questions to ask - thanks for the additional information you’ve already provided us!
Thanks for you reply. Now this is getting helpful! Let me know if I should try something out, e.g. a config option in the apache2.conf file or so.
Problem solved!
I analyzed the server log and noticed that OmniPlan first does a HEAD request (server reply 200), then a PUT request without authorization data (server reply 401), it then retries with authorization data and gets a 412 reply. I further noticed that it was trying to PUT a .xml file.
It turns out that mod_deflate was installed and that it was configured to add a DEFLATE header to .xml files. Turning this off made the problem go away.
I still consider this a bug in OmniPlan’s syncing code, but at least there is now a workaround.
I hope the OmniPlan developers will eventually find a proper solution. Here is how to repeat:
- Install Apache 2 (I use the 2.4 version)
- Install and activate mod_deflate
- Make sure it is configured to treat .xml files (should be by default)
- Publish a document, make a change and re-publish. Enjoy OmniPlan trying to sync forever.
Hi, I’d like to follow up on this question. I have similar problem with Ompniplan, however, as my team is using a company provided webDAV server I cannot simply install apache and activate mod_deflate there. Is there a chance that Omniplan will fix this situation for pro corporate customers?
Thanks.
