SOLVED: Bad Gateway (502) Error using Bingodisk

[FJCsar]

So I decided to take the $20 Bingodisk plunge after reading of others successes and am running into a 502 "Bad Gateway" error.

My settings are set to https://<login>.bingodisk.com/bingo with the ID of "<login>@bingodisk.com" and the proper password.

When I look at the disk, it has a bunch of "OmniFocus.ofocus-copy-in-progress-<string>" folders, with files in them, but I consistently get the 502 error.

Has anyone else resolved this error?

[EdwardA]

I have problems that others appear to share with other WebDAV servers. For the record, bingodisk does not work for me. WebDAV sync appears to work, and the blue bar moves to the end within about 10 seconds. I used the following URL: https://USERNAME.bingodisk.com/bingo/mobile (I created the "mobile" directory manually with Finder.)

However, OF then says that sync failed, and the error message is the following:

Unable to synchronize database with server.

Unable to perform WebDAV operation.

The server returned an error 502, “bad gateway”.

When I use Finder to look in the directory, I find the following:

OmniFocus.ofocus-copy-in-progress-xxxxxxx,

which contains a bunch of zip files but is just not complete. I have not tried plain http because I am not interested in a non-encrypted transmission channel.

Could this be some sort of timeout issue that can be adjusted? Are there any suggestions? I am using OS X 10.5.4, OF 1.1 v77.4.0.102827, and v77.4.0.102830 fails the same way. Thanks.

[EdwardA]

I have the exact same problem. Sorry I didn't see your thread before making my own post.

[Brian]

try using just the username, without @bingodisk.com; does that work? Their 'getting started' page isn't clear whether they want it with or without that.

[EdwardA]

No, the username needs "@bingodisk.com" to work at all.

I did some testing with bingodisk's WebDAV performance (just with the Finder) and found it to be very slow. I have some information from the bingodisk parent company's tech support (Joyent). I asked them about the speed of small file creation which appears to take at least a second or two, and here was their response:

Indeed creating a file is a little slow. These is on top of a zfs file system so creating the meta data is what is taking some time. So uploading a single 1G file is way faster then uploading 1000 1k files.

This is frustrating because the OF sync's blue bar moves step by step about 3/4 of the way across, then rapidly finishes with the failed sync and the bad gateway message. It almost works.

Any other ideas?

[dbfowlersf]

Same 502 Error "bad gateway" error here - but here's the odd part:

Installed on Home machine (iBook G4 running 10.4.1) and set up WebDAV syncn - bravo, it runs perfectly. Creates OF file on WebDAV - but after the first synch on yesterday's build

Same build on Work machine (MacBookPro running 10.4.1) and the same WebDAV setup - synch fails, and fails, and fails.... Never synchs to file on BingoDisk, but instead produces incessant "copy-in-progress" folders... 356 of them in 5 hours this afternoon.

Been keeping both machines on same build - not running app at same time - but no luck getting Work machine to synch up.

Since I've done a bunch of updates on the Work machine, would love to avoid losing that data - ideas on how I could save the data but reinstall the app?

[dbfowlersf]

Did two things:

First, rebuilt my OF database (File -> Rebuild Database)

Second, checked the text in the WebDAV location and discovered I'd errantly left "https" when in fact BingoDisk is "http"

So, looks like it may have been a PBCAC error in my case....

(Problem Between Chair And Computer)

Doh!

[EdwardA]

First, bingodisk can be used with the finder or your browser with http or https. Bingodisk with https connection also partially, at least, works for me with OF. However, with the latest version of OF (see below), I get the following additional information with the error. (My earlier posts show my configuration details.)

Unable to synchronize database with server.

Unable to perform WebDAV operation.

The USERNAME.bingodisk.com server returned "bad gateway" (502) in
response to a request to "MOVE
/bingo/mobile/OmniFocus.ofocus-copy-in-progress-kqJntkVpsw_".

(v77.7.0.103077)


I hope that this will help Omni narrow down the problem. I'll keep trying new ideas that I read about in the forums. I've tried rebuilding the database and removing spurious *.client files in the sync package (these extra *.client files seem to be created every time one switches between disk sync and WebDAV sync---something that one might do frequently when trying to get sync to work!). These things have helped clean things up, but the above problem persists as before.

I welcome any new ideas. Thanks.

[Ken Case]

Sorry for the delay in figuring this out!

The quick summary: BingoDisk works fine over the unencrypted http protocol, but has a bug in the way it handles WebDAV requests over the encrypted https protocol.

The details:

This problem is in BingoDisk's handling of the WebDAV MOVE command. OmniFocus uploads all its data into a temporary location (the one with "copy-in-progress" in the name), and when it's done it moves it into its final location using the WebDAV MOVE command. The MOVE command operates on two URLs, the source and the destination, so if we want to move https://demo.bingodisk.com/bingo/OmniFocus.ofocus-copy-in-progress-huGoIbSftao to https://demo.bingodisk.com/bingo/OmniFocus.ofocus we're supposed to connect to https://demo.bingodisk.com/ and send this WebDAV command:


MOVE /bingo/OmniFocus.ofocus-copy-in-progress-huGoIbSftao HTTP/1.1
Host: demo.bingodisk.com
Destination: https://demo.bingodisk.com/bingo/OmniFocus.ofocus


Unfortunately, as we've seen, this returns a Bad Gateway error: the BingoDisk server thinks that the destination is on a different server (because it doesn't realize that it's serving "https" and not just "http"), so it returns "Bad Gateway" to indicate that it can't do the move. If we modify our code to send an "http" destination instead (even though we're really connecting to https), it succeeds—but that could break other servers which do correctly understand that we're connecting to an https URL (and could legitimately refuse our request if we tried to change the destination to http instead).

I'll give this some thought: perhaps if the legitimate request fails, we can just rewrite our request to try the other destination and see whether that works. It would make things a bit slower, but at least it wouldn't fail altogether!

[Ken Case]

OK, I think I've solved this for the next sneaky peek build (revision 103085 or later):

When a secure WebDAV server returns Bad Gateway (502) in response to a MOVE operation, OmniFocus now retries its request using an http destination URL. This works around a WebDAV implementation bug on some servers (such as BingoDisk) which don't correctly handle https destination URLs.

[EdwardA]

Sync appears to work now with BingoDisk and HTTPS. I have not verified that the actual synchronization works between two machines yet, but the files are now written to the WebDAV server. Thanks for the workaround.

I have also notified BingoDisk's parent Joyent tech support about their issue, and they said that they would check into it and get back to me. I'll post an update when there is one.

[lhotka]

Make sure you update it on the phone/touch too.

[lhotka]

I spoke too soon - I'm getting a 'bad gateway' error on the iTouch. Any idea on how to fix that there?

[Ken Case]

On the iPhone and iPod touch, this isn't fixed until 1.0.2. (This problem was fixed on both sides in revision 103085, but the current 1.0.1 release of OmniFocus for the iPhone and iPod touch is*from revision 102925.)

[lhotka]

On the iPhone and iPod touch, this isn't fixed until 1.0.2. (This problem was fixed on both sides in revision 103085, but the current 1.0.1 release of OmniFocus for the iPhone and iPod touch is*from revision 102925.)

And the obvious follow-up question....

ETA on release? :-)

[Andrew]

We are of course interested in getting these fixes out to users as soon as possible, but I'm afraid we don't yet have an ETA.

[lhotka]

Ah well, I'll just wait to start using it then - it's useless without syncing. My vote is still for sync.omnigroup.com as a new service :-)

[chrjohns]

I have had success on the iPhone using just http (not https).

[lhotka]

Not an option, I won't pass either my password, nor my data unencrypted on a public network.

[Orc]

I won't open another thread for this but I get 502 errors at home when trying to sync OmniFocus 1.1 (v.77.7.0.103348) on my MBP to my WebDAV server which is on a 10.4.11 G5/Quad workstation.

I'm using http rather than https (I'm on my own NATed net).
Any suggestions?


(Was I too eager when buying OF for my iPhone, the other day hoping that WebDAV sync would work?)

[FYI: MobileMe, Bingodisk or any other foreign service is an option]

[lhotka]

I won't open another thread for this but I get 502 errors at home when trying to sync OmniFocus 1.1 (v.77.7.0.103348) on my MBP to my WebDAV server which is on a 10.4.11 G5/Quad workstation.

I'm using http rather than https (I'm on my own NATed net).
Any suggestions?


(Was I too eager when buying OF for my iPhone, the other day hoping that WebDAV sync would work?)

[FYI: MobileMe, Bingodisk or any other foreign service is an option]

You don't want to use a remote service, as it doesn't support HTTPS ( and sending your password plaintext is an accident waiting to happen).

When I was experimenting with HTTP (local network, not a hotspot obviously), I had to delete the database on the iTouch, then resync, then it worked. Sometimes it'd fail, but if I tried again, it'd work again.

[kingsinger]

Any more info on this?

[lhotka]

Nope - I abandoned the attempts to get HTTPS working with bingodisk, when I realized that my corporate policy prohibited me from using a third-party provider. I'm waiting for the direct sync version to be released.

I absolutely can't get HTTPS working with a local WebDAV server due to certificate issues.

[Colby]

An article at:

http://keelypavan.blogspot.com/2009/02/webdav-move-method-fails-with-502-bad.html

may provide a possible solution for the Omni Devs. It indicates that a relative link may work more easily than specifying the entire URI. Obviously, users have no control over this feature. I am only surmising that they are not currently using a relative location due to the consistent problems with WebDAV MOVE (I am using my own WebDAV server).

[Colby]

Pondering the "relative link" issue that I posted about above, I began to wonder if there was anything I could do on my end to avoid the problem.

I experimented with Apple's strange notation for localhost which is formatted thusly:

http://yourusername-emac.local/omnifocus/

where you'd have to substitute for your own info accordingly (I'm using the omnifocus directory to sync with WebDAV). After placing this information in the OmniFocus Syncronization Preferences panel, Advanced tab, Location text box, OmniFocus reports that it is syncing successfully. Now to try with https and the iPhone...

[Ken Case]

It indicates that a relative link may work more easily than specifying the entire URI. Obviously, users have no control over this feature. I am only surmising that they are not currently using a relative location due to the consistent problems with WebDAV MOVE (I am using my own WebDAV server).

We'd love to use a relative link. Unfortunately, Section 9.3 of the WebDAV standard (http://tools.ietf.org/html/rfc2518#section-9.3) says that the Destination header must use an absolute URI, not a relative URI. Some WebDAV servers accept relative URIs anyway, but some don't.

Now, as for the configuration of your personal WebDAV server: are you running it on 10.4 (with Apache 1) or 10.5 (Apache 2) or something else? We recently modified our Bonjour server configuration for Apache 1 on 10.4 to use a mod-perl rewrite rule which automatically reformats the Destination header to always match what the server thinks it is, solving the Bad Gateway problem. You could easily grab our mod-perl script (which ships inside OmniFocus.app) and use it in another Apache 1 configuration.

If you're using Apache 2, it's even easier: you can use the "RequestHeader edit" directive to rewrite the Destination header to match your local protocol and hostname, as described in this article (http://blog.cykyc.org/2008/11/modproxy-moddav-destination-header-and.html).

Hope this helps!