200 is the ok response, it means the server has sent the requested resource. 304 not modified means the object is in the browser cache, the browser has checked.
If you've hit reload you may be running into a browser issue, not a server issue. You've told it to reload, so it goes to the server. Try loading that resource by going into the URL and hitting "enter", not "reload".
Try the "live http headers" plugin for Firefox, it shows what's going on well.
Based on what you've said I don't think there's actually a problem, but you'd need to post the output from Live HTTP Headers for us to be sure. If you do that don't just use one resource, load a static html page and have it refer to a jpg on the CDN.
You can add custom headers to the response from CloudFront / S3 using a Lambda@Edge function. The lambda code runs within the local edge locations, but needs to be created and maintained in the us-east-1
region.
The example code here uses nodeJS 6.10 to add the x-frame-options
response header, but you can add any header that is not restricted by AWS.
'use strict';
exports.handler = (event, context, callback) => {
const response = event.Records[0].cf.response;
const headers = response.headers;
response.headers['x-frame-options'] = [{"key":"X-Frame-Options","value":"SAMEORIGIN"}];
console.log(response.headers);
callback(null, response);
};
Create a definitive version of the Lambda, then set the Lambda Version's trigger configuration as the CloudFront origin-response
Event type for your path pattern behavior.
The example code logs events to CloudWatch logs service for debugging purposes. If you don't already have one you will need to setup a lambda execution IAM role that allows a policy allowing CloudWatch logs actions to be assumed by edgelambda.amazonaws.com
and lambda.amazonaws.com
.
Basic Lambda Execution Policy allowing logs to be written to CloudWatch:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:*",
"Effect": "Allow"
}
]
}
Trust Relationship allowing Lambda and Lambda@Edge to assume the role :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"edgelambda.amazonaws.com",
"lambda.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
It would be better if AWS simply allowed the custom headers to be set using the CloudFront GUI but until then this solution should satisfy your requirement.
Best Answer
It's not a bug.
It's more like a case of imprecise descriptions of what the radio buttons actually mean.
Use Origin Cache Headers
actually means "Use origin cache headers constrained by standard values for CloudFront internal TTLs."Customize
actually means "Use origin cache headers constrained by custom values for CloudFront internal TTLs."The origin cache headers are always used, with either selection. The only difference is whether you're using the standard 0/86400/31536000 values or custom values... so "Customize" with no customized values is exactly the same behavior as "Use Origin Cache Headers," which is why the UI reverts the way it does.
It is not clear why the UI uses descriptions that are somewhat at odds with the actual behavior.