I'm using a CDN (Level3) for the first time and I'm a bit confused. I'm accessing dynamic URLs such as http://cdn.mysite.com?getItem=1234 that return text data.

  1. Do CDNs work with HTTP POST operations? When i issue a HTTP POST operation, my "real" server receives this request every time, so I'm wondering if the CDN has a problem with POST operations.

  2. If i use HTTP GET it seems to work, i call the URL once (from my application), i can see my server receiving the request. If i call it a second time, the CDN delivers it directly, my server doesn't get anything. However if i open same the link manually from a second browser tab, my server is asked to deliver again, shouldn't it be cached by now?

  • 2
    Spend a little while thinking about the anatomy of an HTTP Post. Do you want that data going to the CDN? Can the CDN replicate any business logic which is in your application, on your server, in your database, by serving static (cached) HTML?
    – Greg B
    Mar 9, 2011 at 14:27
  • well i did change my requests to GET and now it works. But it's still confusing, according to several sources i should use POST for unsafe operations (like uploading a file). I can however use POST to simply fetch data, without any business logic attached, so why wouldn't my CDN be able to serve me back static data requested via POST.
    – iddqd
    Mar 29, 2011 at 10:24
  • POST implies you want to send some data to the server. Why wouldn't you just use GET when all you want to do is GET data?
    – Greg B
    Mar 29, 2011 at 11:35

1 Answer 1


Some CDNs may work the way you want them when you submit a HTTP POST request. It depends on what has been configured and what headers/content you submit. Documentation should be available and explain what is possible. Some Perl programmers I've read about turn their heating on and run a bath via HTTP POST requests. This is why POSTs are unsafe operations. They could do anything. You're also going to have to read the status code and whatever media type is returned (if any).

The guide on status codes for the response codes you receive should give you a rough indication on whether the problem is client side or server side. Although there is more than one way to interpret the standards. Generally (assuming everything is configured correctly) any 400-417 status codes indicate bad behaviour on behalf of the client and any 500+ status codes are bad behaviour on behalf of the CDNs server(s).

There may not be a response. You can try a HTTP OPTIONS request and see if POST is listed. To cut down on outbound bandwidth costs, some servers will not respond to certain requests (including HTTP OPTIONS) and application firewalls, reverse proxies, layer 7 firewalls, etc can drop them further upstream.

If for some reason your application has to make HTTP POST requests then you could always use a reverse-proxy. This would eradicate the CDN advantage (you can just get plain on-line storage cheaper, i.e. Amazon S3 without CloudFront). Your own CDN may also be able to configure HTTP POST behaviour on a User-Agent basis, solving the problem, if not find one that will.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.