Re: RFR (testbug) 8218133: sun/net/www/protocol/http/ProtocolRedirect.java failed with "java.net.ConnectException"

[Chris Hegarty]

On 31/01/2019 19:23, Daniel Fuchs wrote:



8218133: sun/net/www/protocol/http/ProtocolRedirect.java failed
  with "java.net.ConnectException"
https://bugs.openjdk.java.net/browse/JDK-8218133

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8218133/webrev.00/


Looks good Daniel.

-Chris.

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

[Daniel Fuchs]

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 
 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

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

[Daniel Fuchs]

Hi Wembo,

On 01/02/19 19:50, Wenbo Zhu wrote:
1) clarify in the API javadoc that chunked encoding is always applied 
even with Connection: close


Chunked encoding is always applied if 0 is passed to
sendResponseHeaders (this is a bit counter-intuitive, but
0 means chunked coding and -1 means Content-Length: 0 or
no content - depending on response code, and n > 0 means
Content-Length: n).

Whether chunked coding is applied or not bears no relationship
with Connection: close whatsoever.

On the client side - if we have 200 with no Content-Length
header and no Transfer-Encoding then we don't expect the
content to be chunked. We simply drain the bytes until
EOF is reached.

Is this what you mean by always applied?

best regards,

-- daniel