1

I'm trying to create a simple webpage for a ConnMan connectivity check from some embedded devices. This library is very finicky about certain things.

The body must be: <html>\n<head>\n</head>\n<body>\n</body>\n</html>\n If anything, even the trailing newline at the end is missing, it fails.

The other component is a response header of X-ConnMan-Status: online. Normally response headers are case insensitive, but ConnMan fails if case is changed at all. This is a seemingly unimportant detail, until you try to host it with AWS.

My first thought was CloudFront (CDN) as it is static content. I also would like to find a serverless solution, as I don't want to manage EC2 instances or K8s pods. I setup a CloudFront distribution with an S3 bucket as the backend to host the simple HTML response. This works great.

I then started exploring various ways of adding the response header. So far I have tried:

All work to add the response header, but Amazon has some crazy obsession with converting the header names to lower case and I need it to be X-ConnMan-Status not x-connman-status. Is there a simple way to host this in AWS where it won't lower case the response header name?

Mike Robinet
  • 823
  • 6
  • 19

1 Answers1

1

I eventually realized that the lower casing of the header names was due to HTTP/2: https://httpwg.org/specs/rfc7540.html#HttpHeaders

header field names MUST be converted to lowercase prior to their encoding in HTTP/2. A request or response containing uppercase header field names MUST be treated as malformed

Disabling HTTP/2 support on the CloudFront distribution, or requesting HTTP/1.1 with the client, preserves the header casing.

Mike Robinet
  • 823
  • 6
  • 19