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.