EOF excption in HTTP 1.1 server interaction
Chris Hegarty
chris.hegarty at oracle.com
Wed May 16 14:58:01 UTC 2018
Bernd,
> On 16 May 2018, at 00:43, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
>
> ...
> For the httpclient code, the following improvements are IMHO possible:
>
> • As you mentioned the EOF should contain the callsite and not be transorted from a worker thread context. This can either be done by rethrwing the EOF Exception or by actually constructing them in the read(). The same (or arguably even worse) Problem is a „connection refused“ type of exception which also has no clear calcite.
Agreed. The synchronous send should recreate exceptions
before throwing.
I filed https://bugs.openjdk.java.net/browse/JDK-8203298
> • Instead of throwing an EOF exception when the read Buffer exceeds the Body lenth I would return a short read till the last available Byte and only throw at the next read. This way the handler can get all of the partial Body. This is however not a good optimization for BodyHander.asString().
Agreed.
I think that the client implementation can provide a more
helpful exception detail message, than what it does today.
I filed https://bugs.openjdk.java.net/browse/JDK-8203302
While maybe not helpful in the string case, it is important
that all response body is delivered to the handler before
EOF. The following has been file to ensure that that is the
case.
I filed https://bugs.openjdk.java.net/browse/JDK-8203303
> It is still unlear why the node.js expresss Server has Problems. For that I think its a good idea to trace it either with Wireshark/tcpdump or Maybe one of the web app Debugging reverse proxies.
It would be helpful to us to understand exactly what the
problem is here. I can try out node.js myself, or if anyone
has some instructions to help set that up it would be
helpful.
-Chris.
More information about the net-dev
mailing list