You are viewing the preview version of this book
Click here for the full version.

Using HTTP redirects

The example code uses a 2-phase fetch, i.e. the frontend first downloads the signed URL, processes it with JavaScript, and finally sends another request to the bucket by inserting an <img> tag, setting the window.location, or sending another fetch. This solution works and it offers less error-prone configurations especially when it comes to CORS.

const req = await fetch("/api/${id}/image");
if (!req.ok) {
  throw new Error("download failed");
const {url} = await req.json();
img.src = await req.json();
With a 2-phase fetch, JS code is needed to get the URL first

Instead of a single <img src="...">, it now requires JavaScript code. Because of this, adopting signed URLs is not transparent to the frontend.

This is usually not a problem for new applications, as you can engineer the frontend this way. But what if you want to migrate an existing backend to use signed URLs? If the frontend is a huge legacy application, it might not be easy to rewrite the affected parts to use the 2-phase fetch.

Fortunately, there is a solution for this right in the HTTP specification: temporary redirects.

Instead of sending back the signed URL in the response body, the backend can return a redirect code and the new location in a header. The browser then automatically follows the link, no JavaScript necessary.

HTTP redirect automatically fetches the image

Using temporary redirects, the backend can be migrated to use signed URLs without even touching the frontend.

But unlike the 2-phase fetch, it brings a few additional complications that you need to be aware of.

There is more, but you've reached the end of this preview
Read this and all other chapters in full and get lifetime access to:
  • all future updates
  • full web-based access
  • PDF and Epub versions