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.fu...@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
