EOF excption in HTTP 1.1 server interaction

[Daniel Fuchs]

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