2

I am using CloudFront to front requests to our service hosted outside of amazon. The service is protected and we expect an "Authorization" header to be passed by the applications invoking our service.

We have tried invoking our service from Cloud Front but looks like the header is getting dropped by cloud front. Hence the service rejects the request and client gets 401 forbidden response. For some static requests, which do not need authorization, we are not getting any error and are getting proper response from CloudFront.

I have gone through CloudFront documentation and there is no specific information available on how headers are handled and hence was hoping that they will be passed as is, but looks like thats not the case. Any guidance from you folks?

coderSam
  • 113
  • 2
  • 6
  • I got my answer on AWS forum and on AWS [documentation](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestBehaviorCustomOrigin). It clearly says headers such as Authorization and Connection will be removed. – coderSam Aug 09 '13 at 17:38
  • Yes, as I mentioned in my answer, there would be no point in passing them through. – ianjs Aug 10 '13 at 07:20

5 Answers5

1

The list of the headers CF drops or modifies can be found here

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustomRemovedHeaders

user2792249
  • 9,123
  • 3
  • 13
  • 3
0

CloudFront does drop Authorization headers by default and will not pass it to the origin.

If you would like certain headers to be sent to the origin, you can setup a whitelist of headers under CloudFront->Behavior Settings->Forward headers. Just select the headers that you would like to be forwarded and CloudFront will do the job for you. I have tested it this way for one of our location based services and it works like a charm.

One thing that I need to verify is if the Authorization header will be included in the cache key and if its safe to do that?? That is something you might want to watch out for as well.

ssekhar
  • 1,049
  • 6
  • 6
0

It makes sense CF drops the Authorization header, just imagine 2 users asking for the same object, the first one will grant access, CF will cache the object, then the second user will get the object as it was previously cached by CloudFront.

Great news are using forward headers you can forward the Authorization header to the origin, that means the object will be cached more than once as the header value is part of the cache "key"

For exmple user A GETS private/index.html Authorization: XXXXXXXXXXXXX

  • The object will be cached as private/index.html + XXXXXXXXXXXXX (this is the key to cahce the object in CF)

Now when the new request from a diferent user arrives to CloudFront GET private/index.html Authorization: YYYYYYYYYYYY

  • The object will be passed to the origin as the combinaiton of private/index.html + YYYYYYYYYYYY is not in CF cache.

Then Cf will be cached 2 diferent objects with the same name (but diferent hash combinaiton name).

Sergio Troiano
  • 79
  • 5
0

In addition to specifying them under the Origin Behaviour section, you can also add custom headers to your origin configuration. In the AWS documentation for CloudFront custom headers:

If the header names and values that you specify are not already present in the viewer request, CloudFront adds them. If a header is present, CloudFront overwrites the header value before forwarding the request to the origin.

The benefit of this is that you can then use an All/wildcard setting for whitelisting your headers in the behaviour section.

user2640621
  • 437
  • 5
  • 7
-1

It sounds like you are trying to serve up dynamic content from CloudFront (at least in the sense that the content is different for authenticated vs unauthenticated users) which is not really what it is designed to do.

CloudFront is a Content Distribution Network (CDN) for caching content at distributed edge servers so that the data is served near your clients rather than hitting your server each time.

You can configure CloudFront to cache pages for a short time if it changes regularly and there are some use cases where this is worthwhile (e.g. a high volume web site where you want to "micro cache" to reduce server load) but it doesn't sound like this is the way you are trying to use it.

In the case you describe:

  • The user will hit CloudFront for the page.
  • It won't be in the cache so CloudFront will try to pull a copy from the origin server.
  • The origin server will reply with a 401 so CloudFront will not cache it.

Even if this worked and headers were passed back and forth in some way, there is is simply no point in using CloudFront if every page is going to hit your server anyway; you would just make the page slower because of the extra round trip to your server.

ianjs
  • 817
  • 5
  • 8
  • I was hoping to use CloudFront network to speed up the response time. Since the network over large distances (such as between US East coast and west coast) or across countries may be slow, I was hoping that Amazon's network and pipes might offer better speeds, even if I cant cache the content. – coderSam Aug 09 '13 at 17:36
  • Cloudfront will be faster if it is able to cache the content. As I mentioned if it can't cache it, the response will actually be _slower_ as the request will go: client -> cloudFront -> your server -> CloudFront -> Client rather than client -> your server -> client. – ianjs Aug 10 '13 at 07:23
  • Agree, but if the client -> your server is over large distances, then the network between client and server may be poorer, and the network from CloudFront edge server to our server may have been better and that the extra hops might get compensated by the faster network of CloudFront. But looks like thats not true as well. And the fact that Authorization header is not allowed makes it unusable for us. – coderSam Aug 11 '13 at 13:45
  • CloudFront will very likely have a better network. You can use it even for strictly dynamic calls and you will expect to see latency go down. Just set TTL to 0. – nashape Feb 13 '14 at 03:06
  • It looks like CF drops the Accept header, which is certainly not a custom header! There goes using the Accept header for API versioning. This is occuring whether you use SSL or not - I guess that means CF is un-encrypting then re-encrypting... – nashape Feb 13 '14 at 04:09
  • Additionally I noticed that it is *not* honouring the TTL of 0 - many of my requests (over about a minute) were not hitting the origin server as expected (although this *could* be because they were 404s). – nashape Feb 13 '14 at 04:10
  • Ok final comment - when making the request through CF you *must* manually set the HTTP Host header to the domain of the origin server. Then all of the headers are passed on. Thanks and g'night. – nashape Feb 13 '14 at 06:52