cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Violation of RFC2616 on some of the Dropbox servers in relation to authentication page

Violation of RFC2616 on some of the Dropbox servers in relation to authentication page

Miikka
Explorer | Level 3
Go to solution

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

 

1 Accepted Solution

Accepted Solutions

Greg-DB
Dropbox Staff
Go to solution

This should be working properly again now. Please let us know if you're still seeing any issues. Thanks!

View solution in original post

4 Replies 4

Здравко
Legendary | Level 20
Go to solution

Hmm... 🤔 Yes, that's correct. There is some misconfiguration probably.

Just for more reference follows example request:

GET /static/fonts/opensans/OpenSans-Bold-webfont.ttf HTTP/2
Host: cfl.dropboxstatic.com
User-Agent: Utility
Accept: application/font-woff2;q=1.0,application/font-woff;q=0.9,*/*;q=0.8
Accept-Language: en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Origin: null
DNT: 1
Connection: keep-alive
Sec-Fetch-Dest: font
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers

... and corresponding response coming from Dropbox:

HTTP/2 200 OK
date: Fri, 21 Jan 2022 13:04:38 GMT
content-type: application/x-font-ttf
last-modified: Mon, 10 Jan 2022 18:30:05 GMT
vary: Accept-Encoding
etag: W/"61dc7b2d-2892c"
x-dropbox-request-id: b26e2c1dffc9fdf9cc92a2bb53939e94
x-content-type-options: nosniff
expires: Fri, 21 Jan 2022 15:51:03 GMT
cache-control: max-age=86400
access-control-allow-origin: *
timing-allow-origin: https://www.dropbox.com
content-encoding: br
cf-cache-status: HIT
age: 73841
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 6d10bfe0cd898ef3-SOF
X-Firefox-Spdy: h2

🤷 Technical support staff should fix this!

Greg-DB
Dropbox Staff
Go to solution

Thanks for the detailed report! I'm raising this with the team. I'll follow up here once I have an update on this.

Greg-DB
Dropbox Staff
Go to solution

This should be working properly again now. Please let us know if you're still seeing any issues. Thanks!

Здравко
Legendary | Level 20
Go to solution

😁 Good workaround! GZIP or nothing... 🙂 Better than before. Matches the specification at least. 😉

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Здравко Legendary | Level 20
  • User avatar
    Greg-DB Dropbox Staff
What do Dropbox user levels mean?