** UPDATED May 4, 2020 ** New header requirements for POST requests starting May 18, 2020

[Gordon-C]

Hello Fitbit Developer Community,

Back in February, Fitbit announced that starting May 18, 2020, all POST, PUT and PATCH API requests will be required to use the Content-Length header, defining the size of the enclosed endpoint body.  This deadline is approaching fast.  To help the Fitbit developer community test their applications, determining if they have implemented the Content-Length header correctly, Fitbit is temporarily scheduling a "brown out" regarding this functionality on Thursday, May 7, 2020 from 13:30 - 15:30 UTC.

This "brown out" is going to force your applications to use the Content-Length header where applicable.  If you have not implemented the header, your application will receive a HTTP Status "411 Length Required".  For those that have successfully implemented the Content-Length header and are just retrieving Fitbit user data, your application will not be impacted.

Again, this requirement is for ALL POST PUT and PATCH API calls.  This is related to operations involving authorization, refresh tokens, creating subscriptions, and creating or updating new fitbit data logs (i.e. activity, food, sleep, etc.).

The deadline to update your applications is May 18, 2020, so please update your code soon.  Any questions regarding this functionality can be posted on our forum, https://community.fitbit.com/t5/Web-API-Development/bd-p/dev, or support form, https://dev.fitbit.com/build/reference/web-api/help/.

---

Over the past several weeks, we’ve received several questions about this announcement.   I’ve modified the original announcement to provide more details and clarification about the new requirement that starts May 18, 2020.

---

According to RFC 7230, section 3.3.2, applications that don’t provide the Transfer-Encoding header, used to define the message body encoding, should include the Content-Length header with the HTTP endpoint request.   The Content-Length header allows the application to define the size of the enclosed endpoint body (and message) being sent to Fitbit and denote where the message ends.

When an endpoint request is sent with the Transfer-Encoding header, the Content-Length header is not required.  RFC 7230, section 4, defines 5 encoding transformation values for the Transfer-Encoding header: “chunked”, “compress”, “deflate”, “gzip” and a transfer-extension.  Fitbit supports the Transfer-Encoding value “chunked”.

Previously, Fitbit did not enforce applications to include the Content-Length header with their HTTP requests.  However, our cloud service provider has started enforcing this requirement. 

Starting May 18, 2020, Fitbit will begin enforcing applications to use the Content-Length header.  The guidelines your application should follow are:   

• The Content-Length header MUST be used
• for all POST, PUT and PATCH requests when the request does not contain the Transfer-Encoding header.   For requests which contain an empty message body, the Content-Length value is 0.
• The Content-Length header MUST NOT be used if
• the request includes the Transfer-Encoding header
• the method is GET, HEAD, DELETE, CONNECT, OPTIONS or TRACE

Failure to provide the Content-Length header will result in your application receiving a HTTP Status 411 Length Required “POST requests require a Content-Length header” message for those API calls.  We suggest that you start making these changes to your application, now, to prevent disruption in May.

The Fitbit Web API support team will be happy to answer any questions about this information in the forums.

[kostya]

Hello @Gordon-C,

According to RFC 7230, section 3.3.2:

A sender MUST NOT send a Content-Length header field in any message
   that contains a Transfer-Encoding header field.

But there is nothing about Transfer-Encoding header in your original post. Could you please clarify if it is enough to send only Transfer-Encoding and not send Content-Length?

[Gordon-C]

Hi @kostya 

My apologies for the delay.   That is a very good question.   I need to confirm one thing on our side and will respond with an answer shortly.   Thank you for your patience.

Gordon

[Gordon-C]

Hi @kostya 

I've updated the announcement to provide more clarity around using the Transfer-Encoding header vs Content-Length header.   Please review and let me know if you're still unclear.

Best,

Gordon

[falinsky]

Hi @Gordon-C .

---

Again, this requirement is for ALL POST PUT and PATCH API calls.  This is related to operations involving authorization, refresh tokens, creating subscriptions, and creating or updating new fitbit data logs (i.e. activity, food, sleep, etc.).

---

What about requests for adding subscriptions? they don't contain body. And also that documentation doesn't mention anything regarding Content-Length header.

Could you please clarify, is it expected that POST requests to add subscriptions must contain Content-Length: 0 headers anyway?

Thanks in advance.

[JohnFitbit]

Hi @falinsky,

Yes, content-length header is required for adding subscriptions even though the request does not contain a body. With that in mind, your request should look like this:

curl -X POST "https://api.fitbit.com/1/user/-/[collection]/apiSubscriptions/[subscriber-id].json" 
-H "accept: application/json" 
-H "content-length: 0" 
-H "authorization: Bearer <access_token>"

I hope this helps! Let us know if you have any questions.

[falinsky]

thank you, @JohnFitbit