Behind the engineering feature teams that work to make Canvas better is the production engineering team, who are dedicated to "keeping the lights on" and delivering excellent and reliable infrastructure. This team is constantly looking for ways to improve Canvas and help you have a better experience. As we continue to invest in our platform, this team is making the transition to fronting many of our applications with AWS CloudFront, more broadly known as a CDN.
What is a CDN and why does this matter? A Content Delivery Network is a large group of servers that helps serve web pages to you from the closest geographical location. Using AWS CloudFront to help host Canvas won't look any different to you when you load Canvas - the URL and look remains the same. But under the hood, the static pages and resources will come from the closest AWS server to you, and is cached across the entire network. This makes the page load faster, is more resilient to availability failures, saves on cost, and improves security.
Understanding the Impacts of CDN Implementation
Canvas's Beta and Test environments have already been served using CloudFront for several months now, and this change will roll out to Production in the next few weeks. It is almost entirely invisible to end users. There are two known side effects that may affect a very small subset of users:
- The primary SSL certificate is now backed by CloudFront, which means that any TLS clients that don’t support SNI (Server Name Indication) will get back a certificate for
*.cloudfront.com, not *.instructure.com. SNI support is widespread and so this has an extremely low chance of causing issues for third-party vendors running very outdated integrations. - CloudFront uses TitleCase for HTTP 1.1 headers. This change is fully described in this blog post.
If you see TLS, HTTP header, or domain-related errors, please contact your CSM and the production engineering team will roll this back for your instance and troubleshoot it. The probability of this affecting anyone is extremely low. And, since Cloudfront is already rolled out in Beta and Test, any institution that would have problems with this will hopefully have already noticed.
GET Requests with Bodies
By default, CloudFront will reject any GET request that has a body instead of query parameters. When we first learned about this requirement, we announced it in the first version of this blog post and worked to see if we could find a solution with AWS that would not disrupt your integrations. We are happy to say that we will not need to enforce this requirement until the summer of 2027.
Historically, Canvas has accepted these requests (since the underlying technology that powers it, Rails, has no trouble with it). But it turns out that GET requests with bodies are somewhat controversial, and not every server accepts them. In fact, many HTTP implementations like fetch have chosen not to allow these requests. The definition of these requests is contained in a few different RFC (Request For Comment) documents, and says that "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request." CloudFront has chosen to interpret this by not allowing these requests, and once we enforce this in 2027, will return a 403 status code.
Impacts for Organizations Utilizing GET Requests with Bodies
So, what happens if you or a vendor has an API integration that sends these kinds of requests? Until 2027, nothing! We will develop further communications and come back to you later. You can change these requests if your app makes them, or wait for further direction.
Thank you for being a part of this journey to a faster and stronger Canvas, and for working with us to help education everywhere!
Note: This post has been updated to reflect that we have partnered with AWS to delay enforcement of the GET Requests with Bodies requirement until later in 2027.
