Question about com.sun.net.httpserver.HttpExchange#sendResponseHeaders

[Wenbo Zhu]

On Fri, Feb 1, 2019 at 9:36 AM Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> 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


Yes, which HTTP/1.1 also respects.

>
>
> > 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.
>
This is a known issue with HTTP/1.

However, with a 200 response, the request body should have already been
read by the time the response body is sent to the client. So RST is
unlikely to happen (assuming no pipelined requests).

>
> 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'd like to propose one of the following changes in httpserver
1) clarify in the API javadoc that chunked encoding is always applied even
with Connection: close
2) or better, allow the application to turn off connection reuse (let's
ignore pipeline for now) - either by supporting "Connection: close" header
or add a new API such as HttpExchange#finishConnection which could be
called any time before #close is called

Being able to disable keep-alive is useful for more than just saving
chunked encoding.

Besides, in case of an early error responses (i.e. when the request body is
still in flight), the server needs to close the TCP connection to be spec
compliant. So the server implementation has to deal with this any way.



>
> > ===
> >
> > 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.
>
This is also good to mention in the javadoc :)  esp. that client-initiated
connection: close is respected, ... and whether chunked encoding is applied
in such a case


> But maybe I misunderstood your question?

Not at all ... and thanks for the point to the httpclient  (didn't know
http/1 is also supported)

- Wenbo


>


> best regards,
>
> -- daniel
>
> >
> > - Wenbo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20190201/1d8ea79d/attachment.html>