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, and improves security.
Understanding the Impacts of CDN Implementation
This change is already available in Canvas's Beta and Test environments, and will soon gradually roll out to Production. It is almost entirely invisible to end users. There are two known side effects that 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. If you see TLS or domain-related errors, please contact your CSM and the production engineering team will roll this back 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 would have likely already noticed. - Cloudfront will reject any GET request that has a body instead of query parameters. 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." The AWS CDN has chosen to interpret this by not allowing these requests, and returning a 403 status code.
Example Requests
Blocked by CDN
curl -X GET --url 'https://<domain>.instructure.com/api/v1/courses' \
-H 'Authorization: Bearer <token>' \
-H 'User-Agent: curl' \
-d '{"state":"deleted"}'
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Bad request.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
<BR clear="all">
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: rDryLQM8TH5eZ1Ko3HfGztEKyvTRsqVy9qzd7otz3XZz4tqpNSxk2g==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>
Allowed by CDN
curl -X GET --url 'https://<domain>.instructure.com/api/v1/courses?state=deleted' \
-H 'Authorization: Bearer <token>' \
-H 'User-Agent: curl'
[{
id: "1",
...
}]
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? We are tracking Canvas instances that recently have had these requests made to them, and will not roll out Cloudfront to these instances until April 18, to give time for these integrations to change to sending query parameters instead of a body. We will notify these affected instances and affected partners soon, and will add a notice to the Developer Keys page only for affected instances that looks like this:
If you don’t see this notice by mid-January, then we have not seen any of these requests coming from your instance and you do not need to take any action. The vast majority of Canvas instances, partners, and third–party vendors are not affected and will be part of the roll out in the coming weeks, with no visible changes to your Canvas.
If you see this notice or already know your instance is affected, you can contact your CSM to confirm that it will be excluded from the initial roll out and get more details. 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 the rollout date is now April 18 for affected instances.
