SOLVED: Bad Gateway (502) Error using Bingodisk
 

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?

Sync not Working with Bingodisk
 

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: [url]https://USERNAME.bingodisk.com/bingo/mobile[/url] (I created the "mobile" directory manually with Finder.)

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

[CENTER]Unable to synchronize database with server.

Unable to perform WebDAV operation.

The server returned an error 502, “bad gateway”.[/CENTER]

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

[CENTER]OmniFocus.ofocus-copy-in-progress-xxxxxxx,[/CENTER]

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.

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

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.

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:

[CENTER][I][INDENT]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.[/INDENT][/I][/CENTER]

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 [I]almost[/I] works.

Any other ideas?

2 machines - same build - varying failures
 

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?

May have solved my own problem...
 

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!

First, bingodisk [B]can be[/B] used with the finder or your browser with http or [B]https[/B]. Bingodisk with https connection also [I]partially,[/I] 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.)

[CENTER][I]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_".

[/I](v77.7.0.103077)
[/CENTER]

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.

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 [url]https://demo.bingodisk.com/bingo/OmniFocus.ofocus-copy-in-progress-huGoIbSftao[/url] to [url]https://demo.bingodisk.com/bingo/OmniFocus.ofocus[/url] we're supposed to connect to [url]https://demo.bingodisk.com/[/url] and send this WebDAV command:

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

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!

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

[QUOTE]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.[/QUOTE]