Archive for June, 2012

Magento Flash Sales Website

June 24, 2012

I am currently working with my team to build a Magento based Flash Sales website for Should be going live in early August.

Alternative to Scene7

June 24, 2012

If you are looking for an alternative to Adobe Scene7 checkout Elasticera.

Search Engine Optimising Images

June 24, 2012

If you are interested in search engine optimising images checkout this blog post on search engine optimising images

Amazon Cloudfront Issues / Enhancements

June 24, 2012

Amazon recently (May 2012) made a significant improvement to Amazon Cloudfront by adding support for dynamic content, i.e. they treat URLs with querystrings as being unique.

Previously Cloudfront treated the following

as if the querystring didn’t exist

I am pleased to say they have listened to users and now have an option to treat querystrings and the order of parameters within them as being unique, i.e. the following are treated as separate cache objects.

There are however still issues or enhancements that need to be addressed with used in conjunction with ELB.

CNAME / Hostname

Cloudfront does not pass the hostname / CNAME of the request to the origin.
For example if a client requests the following URLs


the origin receives the ELB name not the hostname so it doesn’t know what the request pertains to.

This is a fatal issue for origin systems that rely on the hostname to look up configuration settings.

A suggested workaround was to create a Distribution per customer but this didn’t work either. There is a limit of 100 Distributions. Another limit worth mentioning is a Distribution can have no more than 10 CNAMEs.

SSL CNAME / Hostname

Cloudfront doesn’t support vanity hostnames when serving traffic via HTTPS.


Cloudfront appears to pass blank to origin. It is therefore not possible to use this data for reporting purposes.


Cloudfront passes to the origin itself as the UserAgent overwriting the original UserAgent information. It is therefore not possible to use this data for reporting purposes.

Caching Non 200 responses

Cloudfront documentation claims “If your custom origin server responds to a CloudFront request with any of the following status codes, CloudFront caches the code for five minutes and writes the results to the access logs.”

  • 204 No Content
  • 305 Use Proxy
  • 400 Bad Request
  • 403 Forbidden
  • 404 Not Found
  • 405 Method Not Allowed
  • 414 Request-URI Too Large
  • 500 Internal Service Error
  • 501 Not Implemented
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Time-out

5 minutes is not long enough. It should be possible to configure Cloudfront to honour cache-control headers I send it. The whole point of Cloudfront after all is to take the load off the origin.

Worse it doesn’t appear Cloudfront even honours the 5 minutes for various 400 requests I have just tested.


Cloudfront stuffs a load of unnecessary information in the response headers, e.g.
X-Cache: Hit from cloudfront
X-Amz-Cf-Id: eLe2RUVe3An_sGU9fJC83_BFZ2HCZh2Pfk8bXd4AErkCcTFFH7ga4A==
Via: 1.0 (CloudFront), 1.0 rrba-ip-pcache-6 (NetCache NetApp/6.1.1D8), 1.1 wbs-ip-ccache-2 (NetCache NetApp/6.1.1D8)

Client IP

Cloudfront does not pass the Client IP address to the origin.

Cloudfront logging

Cloudfront log format does not include original CNAME requested.

#Version: 1.0
#Fields: date time x-edge-location sc-bytes c-ip cs-method cs(Host)
cs-uri-stem sc-status cs(Referer) cs(User-Agent) cs-uri-query
2012-06-25      13:44:21        LHR5    6184  GET /NexTUmvuchVSXe7Y3ThHidh9lGcj.jpg?w=225&g=1&m=1 200     -
Mozilla/5.0%20(Windows%20NT%206.1)%20AppleWebKit/536.5%20(KHTML,%20like%20Gecko)%20Chrome/19.0.1084.56%20Safari/536.5       w=225&g=1&m=1
2012-06-25      13:08:45        LHR5    7375  GET   /NexTUmvuchVSXe7Y3ThHidh9lGcj.jpg?w=225 200 -
Mozilla/5.0%20(Windows%20NT%206.1)%20AppleWebKit/536.5%20(KHTML,%20like%20Gecko)%20Chrome/19.0.1084.56%20Safari/536.5       w=225

I can’t tell looking at the log file whether http or https either. Nor can I see how long CloudFront took to process the request.

Other issues

These have been reported by other people and if the issues still exist it would be great if they were fixed.

“The bottom line is that requests that send an If-Modified-Since to CloudFront and get a 304 back will essentially lose the Cache-Control hints. If your Expires header is missing, or in the past, the resource will be conditionally validated on every page navigation until it gets evicted from the cache. That can cause a lot of unnecessary requests and will slow down your visitor’s page loads.”

If this behaviour is still the norm can we have an option so CloudFront can be configured not to do this, i.e. if visit on 29th day client would receive instruction to cache for 30 days

“Let’s assume you have just implemented CloudFront for your newly launched website, and decided to use Cache-Control: max-age=2592000, thus allowing CloudFront (and browsers) to cache your object for 30 days. The Date header is cached at CloudFront, themax-age value also remains the same, what changes is the current time at your visitors’ browser. 5 days after launch, your object would only be browser cacheble for 25 days. After 29 days, it would be cachable for 1 day. If the a user visited your site on day 29, then again on day 31 then both these visits would result in a request being made to CloudFront since the first visit had a cache_ttl of one day only.”


If you agree please fill out the Cloudfront survey