Closed Bug 1344480 Opened 7 years ago Closed 7 years ago

Firefox 51 calls /info/configuration with API 1.1

Categories

(Firefox :: Sync, defect)

51 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: jenskali, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161129173726

Steps to reproduce:

I’m using an own Weave Minimal Server with the old sync protocol. Everything works fine up to this version including:
User-Agent: Firefox/50.0.2 (Windows NT 6.1; WOW64) FxSync/1.52.0.20161129173726.desktop

After upgrading to version 51.0.1 the synchronization isn’t working anymore. 



Actual results:

The error-sync log reveals, that Firefox is trying to fetch the server configuration with URL http://my-own-server/weave/1.1/my-user-string/info/configuration, but this fails.

According to https://docs.services.mozilla.com/storage/index.html there is no command for /info/configuration in API v1.1 but in v1.5. Is Firefox 51 working correctly, when it calls the URL .../1.1/.../info/configuration?
Component: Untriaged → Sync
Sync will handle a failure calling that end-point (so yes, it's working correctly), but we have been removing support for 1.1 clients over the last few releases - you should look into self-hosting the more recent servers.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
> we have been removing support for 1.1 clients over the last few releases

We've had a couple of questions this year about the sync 1.1 stack, perhaps we should set and publicize an explicit timeline for removing it, and land a patch that explicitly disables it to avoid any ongoing confusion.  Mark, thoughts?
Flags: needinfo?(markh)
(In reply to Ryan Kelly [:rfkelly] from comment #2)
> > we have been removing support for 1.1 clients over the last few releases
> 
> We've had a couple of questions this year about the sync 1.1 stack, perhaps
> we should set and publicize an explicit timeline for removing it, and land a
> patch that explicitly disables it to avoid any ongoing confusion.  Mark,
> thoughts?

There's nothing in the code that handles 1.1 vs 1.5 - we just use the URLs we are handed by the token server, and although they typically include the version as part of the URL, nothing in the client cares. We do write "client" records which implies we support 1.1 - I opened bug 1345023 to fix that.

Unless I'm missing the point?
Flags: needinfo?(markh)
> There's nothing in the code that handles 1.1 vs 1.5

I was thinking of a more explicit disablement - look in prefs for evidence that the user is syncing against a sync1.1 server, and if they are then take some action to let them know this is no longer supported.  Show a warning?  Disconnect from sync?  I'm not sure what the right move would be, but doing something explicit might be better than letting users get confused as their sync experience slowly degrades.
From our IRC conversation, given Bug 1296767 I don't think there's much more we can do here - browsers connected to legacy sync servers will stop working as that bug rolls out to release.
You need to log in before you can comment on or make changes to this bug.