2013-02-11 51 views
0

我正在向HTTP服务器发送HTTP请求,该服务器合法地返回HTTP响应代码= 200(空)的空白响应。如何避免来自HttpURLConnection的空HTTP响应的EOFException?

但是,这将导致明显的线下抛出EOFException

InputStream responseStream = httpURLConnection.getInputStream(); 
final String contentEncoding = this.connection.getContentEncoding(); 
if ("gzip".equalsIgnoreCase(contentEncoding)) { 
    responseStream = new GZIPInputStream(responseStream); // throws EOFException 
} 

有可能是防止这种明显的方式,但我不能找到它。在创建GZIPInputStream之前,我是否应该检查类似connection.getContentLength() > 0responseStream.available() > 0?这些看起来都不太对,我在示例代码片段中没有遇到类似的东西...

回答

3

我应该算得上检查类似connection.getContentLength()> 0

是。

或responseStream。available()> 0

绝对不是。 available()== 0不是EOF的有效测试,Javadoc明确地这样说。

+0

非常感谢 - 看起来像getContentLength()那么。我只关心一点,我不想引入可能排除有效响应的检查 - 您是否知道内容长度是否始终保证由服务器正确设置? – 2013-02-11 22:23:42

+1

@SteveChambers内容长度也许是HTTP 1.1中所有内容中最重要的标题。如果设置不正确,服务器会严重损坏,浏览器也无法使用。 – EJP 2013-02-11 22:41:50

1

您的服务器不应该返回HTTP代码204(无内容)而不是200吗?除了是一个HEAD请求。请参阅Http Status Code definition

除此之外,您确实可以检查以解决看起来像一个不是所有符合要求的服务器实现的情况,或者捕获该异常,然后根据您发送的请求类型确定适当的操作。

+0

有趣的一点,我同意204会更好 - 但我无法控制这一点,并认为200空白回应是有效的 - 虽然可能不是“标准”。如果可能的话,我宁愿避免发生异常,这违背了我的编程本能。我喜欢在Eclipse中进行调试,并捕获任何类型的Exception作为断点 - 通常这应该表示错误而不是异常数据。 – 2013-02-11 22:09:08

1

我的理解是,您的问题是,每当您收到来自服务器的200响应时,都会抛出此异常。

如果responseStream.available() > 0是不是一种选择,这意味着流实际上包含的东西,但流似乎是不完整的或通过任何其他方式提前结束,因为available指出,有流中读取的字节数。


更新

基于您的评论(并重新读取InputStream的DOC出的纯粹的好奇心后),我也相信connection.getContentLength() > 0是要走的路。如果您使用的是Java 7,那么最好使用connection.getContentLengthLong(),因为它直接返回long

考虑什么文档说约InputStream#available

类InputStream可用的方法总是返回0

而且

注意的是,虽然InputStream的一些实现将返回流中的总字节数很多都不会。使用此方法的返回值分配旨在保存此流中所有数据的缓冲区永远是不正确的。

这放弃了作为选项的检查。

+0

我并不总是得到异常 - 服务器有很多200-OK响应包含数据,但是这个响应不包含数据。实际的用例是作为异步数据流的一部分发送给服务器的ACK。服务器回复200(OK),但没有更多要说的内容(即回应为空)。 – 2013-02-11 22:20:26

+1

@SteveChambers所以我的假设是错误的,我对此表示歉意。我也相信'connection.getContentLength'(或者'connectionlgetContentLengthLong',如果可能的话)是可选的。 – Gamb 2013-02-12 13:11:25

+0

谢谢,这很有帮助。我用connection.getContentLength()看到了很好的结果。 – 2013-02-12 14:44:26

0

除非我遗漏了一些东西,否则根据定义,Content-Encoding“gzip”的响应不能为空。

+0

不知道你是否打算扩大这个范围,但目前它似乎更多的是评论而不是答案 - 也许提供了一个参考资料,说明为什么它不能是空的(我认为这将在HTTP规范的某个地方?)无论如何,有时候一个规范说什么,实际上可以做什么是不同的 - 这个问题描述了看到的内容,而且似乎其他人可能看到了类似的内容[这里](http://stackoverflow.com/questions/22831793)和[这里](http://stackoverflow.com/questions/40251180)。 – 2016-11-09 17:11:49

+0

如果服务器显示“content-encoding:gzip”,那么必须对负载进行gzip压缩;根据定义,空的有效载荷不会被压缩。因此HTTP响应无效。 – 2016-11-09 17:29:04

+0

这听起来合乎逻辑,但是IIRC的问题是关于收到的响应超出了我的控制范围,仍然需要适当处理。猜测第一句中的“合法”一词可能是错误的。 – 2016-11-09 19:09:52

相关问题