User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release) Build ID: 20130814063812 Steps to reproduce: Setup private sync server (FSyncMS) on private server with non-standard SSL port (say 40000 for this example). Account creation using menu entry "Set up Sync..." worked fine with server URL https://my.domain:40000/fsyncms/index.php/, but subsequent synchronization did not work. Apache access log on private server showed registration accesses, but none thereafter. Searching for "sync" in about:config revealed that services.sync.clusterURL had stored the server URL without the port (i.e. https://my.domain/fsyncms/index.php). Manually adding the port fixed the problem and sync worked thereafter. Actual results: Firefox Sync account setup does not store the port in services.sync.clusterURL in about:config Expected results: Firefox Sync account setup should automatically add the port to services.sync.clusterURL
Component: Untriaged → Firefox Sync: Backend
Product: Firefox → Mozilla Services
Version: 23 Branch → unspecified
This could also be a bug in FSyncMS, if it's not correctly sending the custom port during the node-assignment process. I've definitely used non-standard ports with a custom sync server in the past, and it's worked fine. I'm not familiar with FSyncMS, is [https://github.com/balu-/FSyncMS/] the canonical source? https://github.com/balu-/FSyncMS/ for development?
Possibly related to these lines of code: https://github.com/balu-/FSyncMS/blob/master/user.php#L115 I don't see any explicitly handling of the port in here. If you're able to capture a client-side sync log using the process described at [https://philikon.wordpress.com/2011/06/13/how-to-file-a-good-sync-bug/] then we should be able to tell whether the server is sending back an incorrect value.
Yes, that's the correct canonical source and the one I used. Luckily the last sync log with the first attempt at syncing was still there, I put it up under http://pastebin.com/dhxJhiJ2. Sorry if I mistakenly took this for a Firefox bug, I naively assumed not a whole lot of people would put up their own server. I'll look into the PHP sources tonight.
Aha, yep. At line 109 in the posted log, you can see that the clusterURL returned from the server does not include the port component. Definitely looks like an upstream bug, so I'm going to go ahead and close this bug out, but thanks for taking the time to report. Feel free to re-open if the issue turns out to be more complex than I thought.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.