EOF excption in HTTP 1.1 server interaction

Simon Roberts simon at dancingcloudservices.com
Fri May 18 14:31:18 UTC 2018


Thanks for all of this Daniel. Yes I finally managed to build curl with
http2.0 support, and I see the same thing.

I hate when one wastes three days (and who knows what of all your time) on
a bug in a tool one was only using as ancillary support because one thought
it would be quick (though hopefully not dirty) and let you get going fast
:(

Sincere apologies for the distraction everyone, and particularly Chris, and
thanks for all the help. I'll go use a server that works.

Cheers!


On Fri, May 18, 2018 at 8:20 AM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Simon,
>
> In complement to my previous answer, please find some
> additional info to your questions:
>
> On 16/05/2018 17:24, Simon Roberts wrote:
> >
> > Notes, as a result of the discussion, I deliberately added code, at line
> > 56 of server.js, to try to ensure that it's sending \r\n.
>
> You don't need to do that. It's only *header lines* that need to
> be terminated with '\r\n' (well, chunks should also be terminated
> with '\r\n' when the body is sent in chunks - but that's handled
> by the server stack. The application data can use any line
> termination it wants in the body of the response).
>
> > This code
> > isn't "normal" in node, but I believe it's irrelevant anyway, as I've
> > already shown that httpClient is failing before it ever processes the
> > body (perhaps the headers aren't being sent with \r\n!?)
>
> They are! :-) Your server stack is doing the right thing. But as my
> fake client demonstrate, the problem is with the upgrade headers.
>
> > Also, I did try, last night, to turn off the HTTP2.0 mode in httpClient
> > using:
> >
> >   HttpClient client =
> > HttpClient.newBuilder().version(HttpClient.Version.HTTP_1_1).build();
> >
> > but that did not change anything.
>
> That's curious, because it works for me. If you've been using your fake
> server then of course, it shouldn't change anything (but the bug is in
> the fake server). If you send it to your 'real' server though, the one
> you start with `npm start` then it should be working.
>
> I tried it both with JDK 11 (my developer's build), and JDK 10
> (downloaded from oracle web site):
> java version "10" 2018-03-20
> Java(TM) SE Runtime Environment 18.3 (build 10+46)
> Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode))
>
>
> > I'll also note that when trying my "trivial serer", it reproduced the
> > problem when it was sending the wrong line-endings.
>
> Yes - but even though the symptom is the same (EOF), because in all
> of these cases, all the client sees is that the connection gets
> closed before the full response is received, that's actually caused
> by three different issues on the server side:
>
>         1. the server decides to close the connection because it
>             doesn't like the upgrade headers
>          2. the server doesn't use \r\n to separate header lines
>          3. the server lies about the response content length and
>             closes the connection before sending all bytes.
>
> 1. is the real issue you observed with your `npm` server, and
>     can be worked around by setting HTTP/1.1 in the client
>     or the request.
> 2. and 3. were only present in your fake server.
>
> hope this helps,
>
> -- daniel
>


-- 
Simon Roberts
(303) 249 3613
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180518/8299335c/attachment.html>


More information about the net-dev mailing list