--- title: "The Harrowing Search for the Elusive Technical Answer" id: "12994" type: "post" slug: "the-harrowing-search-for-the-elusive-technical-answer" published_at: "2022-09-07T14:30:00+00:00" modified_at: "2022-09-06T23:07:28+00:00" url: "https://www.lastweekinaws.com/blog/the-harrowing-search-for-the-elusive-technical-answer/" markdown_url: "https://www.lastweekinaws.com/blog/the-harrowing-search-for-the-elusive-technical-answer.md" excerpt: "Hey, Google, please crawl this meta description! \"How to set a static header on an AWS v2 API Gateway to enable HSTS.\" xoxo, Corey Quinn" taxonomy_category: - "Uncategorized" --- It’s a pattern that has haunted me my entire career. It starts like this: 1. Encounter technical problem. 2. Search in vain for an answer. 3. Lose all hope. I once again stumbled through this sequence while I was puttering around with my Last Tweet in AWS Twitter shitposting client recently. Allow me to take you on a little journey through my painful experience. ## Corey encounters a technical problem In case you hadn’t heard of it before, [Last Tweet in AWS](https://lasttweetinaws.com) is a free-to-use Twitter client that makes creating threads easier while providing passable image recognition + OCR to create alt-text for images. It’s built atop serverless technologies, and it’s served from 20 AWS regions, depending on which is the closest to the user. Because it uses AWS’s API Gateway v2, or “HTTP APIs,” it only listens on port 443 via TLS. That service will not listen on port 80. This is fine; I don’t want people passing sensitive data in plaintext! The problem I run into is when I forget to explicitly put an HTTPS in front of the domain, then a service (such as, amusingly, Twitter) attempts to direct traffic to port 80 instead whenever anyone clicks the link. When this happens, the connection attempt fails, and it appears to all the world as if there’s no website working at the domain in question. There’s no *great* answer for this that doesn’t dramatically overcomplicate things. The official AWS answer is to go ahead and slap CloudFront in front of the site. Great; genius plan. That would mean that I’d need to either configure 20 origins for the CloudFront distribution and find some way to get them to pick the closest one to the user or else undo the benefit of having a multi-region setup. Every request is dynamic, so there’s no caching story that makes sense. This was the state of things when I found the one answer that at least somewhat mitigates the concern. In 2012, a standard was released called [HTTP Strict Transport Security](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) . While fairly complicated (because this is the internet, after all), it states that a website can return a header named `Strict-Transport-Security` that specifies a length of time. Browsers remember that and, for the length of that time, refuse to even attempt to connect to the site over an unsecured connection. While that works well for folks who have visited the site before, a combination of traffic analysis, a careful counting of the number of commas in my AWS bill, and basic arithmetic all indicate that far more people have not visited Last Tweet in AWS than have done so before — so what good does this do for 99.9999% of the internet’s population? This is where the [HSTS Preload List](https://hstspreload.org) comes into play. This is a list of domains that return the proper header, and it’s periodically loaded into all major web browsers. Once a domain is added to this list and circulated to the browser providers, this problem gets solved for basically everyone since the browser will fail to even attempt to connect on port 80 — though the process does take months. My problem, and the reason for this post, was in figuring out how to set a static header on the v2 HTTP API. ## Corey searches in vain for an answer A few things make this a very hard thing to research online. “API Gateway” is a common term. “HTTP API” is such an incredibly overbroad term across all manner of vendors as to be effectively impossible to search for. Most combinations of search terms that I tried, both on Google and (begrudgingly) on AWS’s own documentation search dingus, led me to the same narrow subset of search results. Now, I’m no $1.434 trillion company, but it seems to me that if you’re running any form of analytics on your documentation traffic, and you see the same user arriving at the same page repeatedly over the course of an hour via a variety of paths, perhaps this might be signal that they’re looking for something that they aren’t finding. I abhor popups when I’m trying to get something done, but the fifth time I’m staring at the same page, wondering what it is I don’t understand, that would be a great time for the documentation to offer to help me more effectively. ## Corey nearly loses hope I finally found the answer via a carefully constructed code search on GitHub, which shouldn’t have been necessary but absolutely worked out in the end. For the record, the answer to my question about implementing a static header for HSTS is “whatever is returning data to the API Gateway, have it insert an arbitrary header into that response and the API Gateway v2 will pass it through without comment” … but that was basically impossible to discover. To set a static header on the v2 HTTP API to enable HSTS, I added the line `res.setHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains; preload");`. (Honestly, making this solution discoverable via Google is half of the reason I’m writing this blog post.) ## Solving for the impossible search process The larger problem is that when we’re faced with a technical challenge, “how do I do this” is the burning question that looms large in all of our minds. We search and we plumb the depths of forum threads that haven’t been updated in a decade, in pursuit of the magic answer that sorts us out. It eludes us, drives us slowly mad — and then we figure it out! See, there are five steps to this harrowing pattern for developers: 1. Encounter technical problem. 2. Search in vain for an answer. 3. Lose all hope. 4. *Eventually discover an answer.* 5. *Don’t bother to publish the answer for the next sucker.* Here’s the problem: None of us goes back to all of those dead ends to update the long-forgotten forum posts. We don’t return to Stack Overflow and update old questions (they’d just get closed as Off-Topic anyway). We don’t hit the surprisingly effective “Feedback” button on the footer of every AWS documentation page. *This* is the problem I don’t have an answer for, and it’s haunted me my entire career. If you have an idea to solve it — and it doesn’t involve paying some sketchy startup a pile of money for unclear value — please reach out to share it with me. Because if not, then you can more or less expect a blog post like this one so that the next poor sot who tries to set a static header on an AWS v2 API Gateway to enable HTTP Strict Transport Security can find the answer easily enough — after reading through the rest of this screed. by Corey Quinn Corey is the Chief Cloud Economist at Duckbill, where he specializes in helping companies improve their AWS bills by making them smaller and less horrifying. He also hosts the "Screaming in the Cloud" and "AWS Morning Brief" podcasts; and curates "Last Week in AWS," a weekly newsletter summarizing the latest in AWS news, blogs, and tools, sprinkled with snark and thoughtful analysis in roughly equal measure. ## More Posts from Corey [Back to the Blog](https://www.lastweekinaws.com/blog/) [https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/](https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/) ### [Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner](https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/) [By Corey Quinn](https://www.lastweekinaws.com/blog/author/cquinn/) Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner AWS has just released something fascinating in the form of CloudWatch Omni. I want to be upfront before I dive further: “CloudWatch Omni” is a wretched name that I will not be using, so for the rest of this article and the […] [Read More about Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner](https://www.lastweekinaws.com/blog/cloudwatch-omni-infinidash-review/) [https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/](https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/) ### [Reading Observability Tools? That’s a Robot’s Job](https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/) [By Corey Quinn](https://www.lastweekinaws.com/blog/author/cquinn/) Last Thursday Honeycomb was kind enough to hand me the closing keynote slot at O11yCon, a conference whose entire premise is that observability matters and the people in the room are the ones who would know. I used that slot to argue that the primary reader of your telemetry is no longer a human, and […] [Read More about Reading Observability Tools? That’s a Robot’s Job](https://www.lastweekinaws.com/blog/reading-observability-tools-thats-a-robots-job/) [https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/](https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/) ### [S3 Is Not a Filesystem (But Now There’s One In Front of It)](https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/) [By Corey Quinn](https://www.lastweekinaws.com/blog/author/cquinn/) I’ve been saying “S3 is not a filesystem” for over a decade. I’ve said it on stages, in newsletters, on podcasts, and directly to the faces of large company employees who were too polite to tell me to shut up before they went back to their FUSE monstrosities. It was one of those reliable truths […] [Read More about S3 Is Not a Filesystem (But Now There’s One In Front of It)](https://www.lastweekinaws.com/blog/s3-is-not-a-filesystem-but-now-theres-one-in-front-of-it/) ## Get the newsletter! Stay up to date on the latest AWS news, opinions, and tools, all lovingly sprinkled with a bit of snark. "*" indicates required fields