JRE HttpServer是否違反HTTP的'expect-continue'語義？

這是一個problems的後續文章我已經使用過內置com.sun.net.httpserver.HttpServer的Java和一個多步認證方案。JRE HttpServer是否違反HTTP的'expect-continue'語義？

我是hinted at，發送更大的數據量使Java客戶端無法接收早期的「需要授權」消息（由於Java阻塞I/O）。

這就是爲什麼HTTP定義了「預計，繼續握手」，涉及100狀態碼（RFC 2616）的原因：

的100（繼續）狀態的目的是爲了讓客戶端是發送請求消息與請求主體一起確定在客戶端發送請求主體之前，原始服務器是否願意接受請求（基於請求標頭）。在某些情況下，可能是不合適的或者對於客戶端來說效率非常低，如果服務器拒絕該消息而不注意正文，則發送主體到。

所以在這種情況下，發送數據是不合適的。服務器...

務必以100（繼續）狀態進行響應，並繼續從輸入流中讀取，或以最終狀態碼進行響應。

不幸的是，太陽HttpServer總是以100個狀態碼響應，而不涉及應用。縱觀source：

/* check if client sent an Expect 100 Continue. 
* In that case, need to send an interim response. 
* In future API may be modified to allow app to 
* be involved in this process. 
*/ 
String exp = headers.getFirst("Expect"); 
if (exp != null && exp.equalsIgnoreCase ("100-continue")) { 
    logReply (100, requestLine, null); 
    sendReply (
     Code.HTTP_CONTINUE, false, null 
    ); 
}

當未涉及的應用，它似乎是不可能的通信的客戶端，這是不恰當的，從而發送其消息的協議違反了（這實際上導致的問題，像早期閉合連接和斷開的管道）。以防萬一我失去了一些東西，我最好問社區，如果這種解釋是正確的:)

來源

2012-02-08 mtsz

我不會說這是違反協議，因爲服務器和應用程序之間的通信不是協議的一部分，只能在服務器和客戶端之間進行通信。只要服務器在發送100-Continue後接受整個客戶端請求，協議就會受到尊重。

當然，自動返回100-繼續意味着您失去了預期 - 繼續打算提供的潛在效率增益，但效率不是協議所保證的。

來源

2012-02-08 16:08:57 antlersoft

作爲這個偉大的答案的附錄，我會補充說，太陽HttpServer有一個_very_有限的使用範圍。對於任何_real_ web服務器需求，您應該使用像jetty，apache或其他高質量java web服務器的主機。 – jtahlborn 2012-02-08 16:45:07

@jtahlborn這個服務器嵌入的項目是一個學術背景，所以afaik還有其他的考慮使用這個服務器，比如它是Java的一部分。我不得不承認Jetty應該是一個更好的決定，因爲幾乎沒有人會使用sun httpserver來處理任何嚴重問題。 – mtsz 2012-02-08 17:32:57

@antlersoft感謝您的回答，但服務器在發送100之後不願意接受請求，因爲客戶端尚未獲得授權。根據http://www8.org/w8-papers/5c-protocols/key/key.html，這是一個滿意的用例。在這種情況下，無法通知sun httpserver它應該避免發送continue消息。但是，它不是核心協議，它只是帶寬優化的邊緣。也許這是不恰當的，稱之爲違反或不......不管怎麼說，這可能不是有趣的...這個問題似乎沒有太多朋友:) – mtsz 2012-02-08 18:02:03

JRE HttpServer是否違反HTTP的'expect-continue'語義？

回答

相關問題