windows的apipost發(fā)送請求后，服務(wù)器響應(yīng)了HTTP/1.1 404 Not Found，但是apipost一直顯示發(fā)送中。
linux上的curl也一樣。
使用wireshark抓包發(fā)現(xiàn)收到了響應(yīng)，但是wireshark識別不了（圖中是回應(yīng)404后關(guān)閉了連接）：
第一個(gè)報(bào)文是HTTP/1.1 404 Not Found響應(yīng)，但并沒有識別出來，wireshark認(rèn)為是一個(gè)不完整的HTTP報(bào)文（TCP segment of a reassembled PDU），但HTTP實(shí)際上是完整的，結(jié)尾帶了兩個(gè)\r\n（0d 0a 0d 0a）：
第二個(gè)報(bào)文是服務(wù)器發(fā)送的FIN，里面并沒有應(yīng)用層數(shù)據(jù)，Len=0：
不清楚為什么認(rèn)為這個(gè)HTTP報(bào)文不完整，只能在服務(wù)器上手動增加了：
FullHttpResponse resp = new DefaultFullHttpResponse(HttpVersion.HTTP_1_1, HttpResponseStatus.NOT_FOUND);
//netty服務(wù)器默認(rèn)不包含CONTENT_LENGTH 需要手動設(shè)置
resp.headers().set(HttpHeaderNames.CONTENT_LENGTH, 0);
之后wireshark抓包正常了，apipost也能收到了：
這是因?yàn)樵贖TTP/1.1中，鏈接是復(fù)用的，如果沒有content-length就無法區(qū)分兩個(gè)HTTP報(bào)文的邊界（粘包），也就是說HTTP/1.1如果是keep alive（沒有connection也默認(rèn)是keep-live），則content-length和chunk必然是二選一。
有一些響應(yīng)碼可以沒有content-length，但404響應(yīng)必須包含body，可以是0，來自RFC2616：文章來源：http://www.zghlxwxcb.cn/news/detail-823409.html
對于響應(yīng)消息，消息里是否包含消息主體依賴相應(yīng)的請求方法和響應(yīng)狀態(tài)碼。所有HEAD請求方法的請求的響應(yīng)消息不能包含消息主體。所有1XX（信息的），204（無內(nèi)容）和304（無修改）的響應(yīng)都不能包括一個(gè)消息主體（message-body）。所有其他的響應(yīng)必須包括消息主體，雖然可能長度為零.
。。。。
服務(wù)器響應(yīng)為40x，除了響應(yīng)HEAD請求，都應(yīng)該包含一個(gè)message-body，message-body包含一個(gè)此錯(cuò)誤請求的解釋。文章來源地址http://www.zghlxwxcb.cn/news/detail-823409.html
到了這里，關(guān)于apipost和curl收不到服務(wù)器響應(yīng)的HTTP/1.1 404 Not Found的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
