Hello,
Since 19th of January 2022 the Dropbox backend servers have started to respond differently to the HTTP request to https://www.dropbox.com/oauth2/authorize?client_id=[censored] - at least some (if not all) of the servers responding add the header:
"Content-Encoding: br"
... i.e. utilize the br-compression for the returned response, even if the requesting client has set only:
“Accept-encoding: gzip, deflate”
Based on RFC 2616, server should obey the guidance given by the client on supported transfer-encodings.
In practice, this makes the login page access fail for clients (browsers) which do not have the "br" support enabled or supported.
The content which seems to use br compression always is coming from the server https://cfl.dropboxstatic.com/static/css - which are refered by the dropbox.com main login page.
This is a problem for a device in market currently, all new Dropbox logins fail.
Can you please see that the backend servers would work as IETF RFCs dictate - i.e. if client does not promote support for br encoding, do not force it.
Thank you and best regards,
Miikka
