Java getContentLength（）只返回int

为了处理HTTP POST或PUT中的大型请求体，依赖

HttpServletRequest.getContentLength（）

不是一个好主意，因为它只返回整数值，对于大于2GB的请求体，返回-1

然而，我认为没有理由不允许更大的请求机构。RFC2616说

任何大于或等于零的内容长度都是有效值

---

使用

HttpServletRequest.getHeader（'content-length'）

并将其解析为Long是否有效？

是的，这是一种很好的方法-使用

getHeader（“content-length”）

（大写）和

Long.parseLong（…）

。我相信这就是容器所做的，但是serlvet规范将其限制为

int

。

自Servlet 3.1（Java EE 7）以来，有一种新方法可用：

这同样适用于响应上的对应项：

---

不确定它是否适用于上传，但您可能还想看看分块编码；2GB在当时是不可想象的。当时是否有1GB的消费者硬盘？RFC2616的日期为1999年。从通信和系统的角度来看，开发需要2G或更多的API在实际应用中是有问题的。假设支持4G，而您只有20个用户，您将需要80G的ram来处理此数据的初始副本。一些应用程序复制部分或全部有效负载数据，将其放入应用程序数据结构中，因此现在80G变成120G到160G，这仅适用于20个用户。这个问题是有效的，但在我看来，规范为“int”对于所有可能不使用HTTP的高速应用程序都足够了。@PatS你是在开玩笑吧？为什么一个流会被保存在内存中？事实上，从另一方面来说，执行

response.setHeader（“Content Length”，String.valueOf（someLong））也是完全有效的。您只需注意某些磁盘文件系统的4GB限制，可能还需要注意服务器的2GB POST大小配置。@McDowell对“chuncked”有一个很好的观点。（我觉得处理>2G文件很奇怪。）@BalusC，你能解释一下服务器的2GB POST大小配置是什么意思吗？谢谢。@BalusC它无效
HttpURLConnection
自动设置此标头，除非您使用的是固定长度或chunked transfer.FWIW，否则没有理由大写。标题名称。标头名称定义为不区分大小写。
long contentLength = request.getContentLengthLong();

response.setContentLengthLong(file.length());