Question about com.sun.net.httpserver.HttpExchange#sendResponseHeaders
Daniel Fuchs
daniel.fuchs at oracle.com
Fri Feb 1 17:36:45 UTC 2019
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
More information about the net-dev
mailing list