参见HTTP RFC：http://www.w3.org/Protocols/rfc2616/r...
HTTP协议的RFC中明确说了，对PUT方法，接收者不能忽视任何Content-* Header，但POST方法没有明确说。这种用法比较冷门，所以，有的Web Server和Proxy很可能不会实现POST方法的Content-Range支持。
GET方法的Content-Range支持是非常普遍的，各种断点续传的下载软件都是靠这个实现的。
开源项目gears上有一篇proposal是讲"POST/PUT 支持 Content-Range"的，你可以参照一下：http://code.google.com/p/gears/wiki/C...
你们的Web Server是自己写的，不存在不支持这个Header的可能，关键就是中间的各类七层代理（负载均衡、反向代理等）。以HAporxy为例，如果打开了keep-alive选项，HAproxy会对后端的Web Server使用HTTP长连接，End User这边发起1000个HTTP请求，HAproxy可能只向后端Web Server发起50个持久连接，这时候，不要说是Content-Range，其它HTTP头也会丢弃。
所以：
1. 如果你不能控制中间的各类七层代理，最好不要使用HTTP协议没有明确规定且不太常用的HTTP Header，改为在HTTP Body里实现。这么做的优点是兼容性好，缺点是性能差一点（相对写在Header中而言）
2. 如果你很在意性能，且不想改动Content-Range的相关代码（从Header移到到Body处理中去），则要有向中间七层代理服务提需求的能力
