Hi Wembo,
On 31/01/2019 23:56, Wenbo Zhu wrote:
Per the HTTP spec, chunked encoding may not be needed if "Connection:
close" is set and the TCP connection will be closed (FIN) to complete
the response body.
Are you referring to HTTP/1.0?
https://tools.ietf.org/html/rfc1945#section-7.2.2
I am yet to write a test for this but the javadoc needs to address this
behavior..
This behavior can be supported using the existing API, e.g. by asking
the application to add the Connection header before #sendResponseHeaders
is called.
We fixed the java.net.http client recently, and
added some tests in the java.net.http test base to verify
that the java.net.http client supported this.
Then we had to fix the tests because under some circumstance,
closing the connection would trigger an IOException on the client
side instead of an EOF. The server has to let the socket linger
long enough for the client to receive the data, otherwise a
"Connection reset by peer" might get triggered on the client
side.
In the absence of Content-length header then it's impossible
for the client to know whether it has received all the bytes
or not when such an error occurs.
So I'm not sure how reliable it would be to implement such
a feature in the com.sun.net.httpserver.
===
I am adding com.sun.net.httpserver. as a lightweight http/1 server
runtime for a framework. The (low-level) com.sun.net
<http://com.sun.net> APIs are very well documented. Thanks for your work
on this library.
FWIW, the tests we added for the HttpClient is there:
http://hg.openjdk.java.net/jdk/jdk/file/tip/test/jdk/java/net/httpclient/UnknownBodyLengthTest.java
It doesn't use com.sun.net.httpserver but a plain ServerSocket
with a canned response.
Unless I'm mistaken setting "Connection: close" in the response
headers from within the Handler in the com.sun.net.httpserver
currently has no effect on the server:
The server has some logic to close the connection if
requested by the client (Connection: close in the request headers),
or if the connection pool has reached its maximum, or if the client
is 1.0 and has not requested keep-alive, or if a protocol/IO/software
error occurs, but otherwise it will keep the connection open.
But maybe I misunderstood your question?
best regards,
-- daniel
- Wenbo
