Box API Response Header Changes

As many of you may have seen, response headers that are returned when making calls to Box APIs are changing on May 10th, 2021. In short, the letter case of the response headers will be standardized as part of ongoing upgrades to our networking and observability infrastructure. Box SDK users are not affected, but direct API consumers may be depending on if / how those response headers are used.

While we have reached out to potentially impacted customers, you may want to double check your Box applications meet these standards. The example below demonstrates how to retrieve response headers from Box and access them in a case-insensitive way, in line with industry best practices and our API documentation.

Sample Setup

In this Node / Express sample, we will make an API call to get an access token from Box. In the response we will also retrieve the headers, which could also be used to help with program flow. There are a few important bits of the code to keep in mind:

I’m setting the request headers for the content type and length. These are not impacted by this release — only response headers are. This means that you do not have to make changes to your existing code when setting these values.

headers: {
  'Content-Type': 'application/x-www-form-urlencoded',
  'Content-Length': req.length
}

Next, once I make the API request to Box and the response is returned, I have a few lines to capture a specific header, Content-Type. Capturing and using API response headers like these are what you’d be looking for in your code, as these are examples of where the potential impact will be since I am checking for a specific letter case of Content-Type as opposed to checking in a case-insensitive manner.

let contentType = response.headers['Content-Type'];
console.log(contentType);

Below is the code sample that we’ll be looking at. I set the details of the request in options, then made a POST request to get a Box access token. Once the response returns we will check for errors, capture the response headers, and then extract the access token/expires in parameters from the response.

Switching to a case-insensitive response header check

Capturing the header like we are above (response.headers['Content-Type']) does not capture the response header in a case-insensitive way. The problem is not necessarily when I am capturing the header, but how it is used. If I expected a certain header to be present and built my program execution on that expectation, I may run into problems.

While there are a number of ways to check these headers in a case-insensitive way, one way is to force all response headers to a specific letter case before using them. To do that:

1. Loop through all response headers.
2. For each header: Store as a key / value pair in a JSON object.
3. For each key: Force the header key (e.g. Content-Type) to lowercase and store as the key.
4. For each value: store the header value without any alterations.

Once that is done, I can check the JSON object for the content-type key (for instance), since I forced all headers to a standard lowercase value. I can then continue program execution as normal, checking to see if the value I needed is available.

To modify the lines where I check for Content-Typeabove with a case-insensitive header check:

There are a few things to note about the code snippet above:

1. response.headers contain all of the headers in the response. I’m using Node / Express in this sample.
2. I loop through each of the headers, store the lowercase header name as a key in the new headers object and store the header value without any alteration. Response header values may or may not be case-sensitive, but if you are expecting a specific letter case for the value it is recommended to force the value to a specific case.
3. In Node, I can force lowercase with .toLowerCase(), which is the header.toLowerCase() piece above.
4. Once I have a new header object with all lowercase headers, I can safely try to use the content-type header as a lowercase value. If it was a header returned by Box it will have a value.

Again, this is just one example of how you may build case-insensitive response header checks within your code. This will not only help increase the flexibility of your application code in the future, but ensure that you build to HTTP standards.