[no subject]
I have a very simple attempt to use the Java 10 / incubator httpclient api.
It works on "regular" resources, but fails horribly when attempting to get
things from localhost. It fails using 127.0.0.1, the actual non-loopback
IP, and the name localhost. The server is running, and presenting a very
simple web page (I originally tried json, but have since simplified it
attempting to find out what's amiss).
The code is as simple as I can imagine (and that might be the problem :)
--
HttpClient client = HttpClient.newHttpClient();
URI uri = URI.create("http://192.168.1.102:8080/index.html";);
HttpRequest getRequest = HttpRequest.newBuilder()
.uri(uri).GET().build();
HttpResponse response = client.send(getRequest,
HttpResponse.BodyHandler.asString());
System.out.println("response to get: " + response.body());
--
The error prints a long stack trace, which I suppose I must post in its
entiretly:
--
WARNING: Using incubator modules: jdk.incubator.httpclient
Exception in thread "main" java.io.EOFException: EOF reached while reading
at
jdk.incubator.httpclient/jdk.incubator.http.Http1AsyncReceiver$Http1TubeSubscriber.onComplete(Http1AsyncReceiver.java:507)
at
jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$ReadSubscription.signalCompletion(SocketTube.java:551)
at
jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$InternalReadSubscription.read(SocketTube.java:728)
at
jdk.incubator.httpclient/jdk.incubator.http.SocketTube$SocketFlowTask.run(SocketTube.java:171)
at
jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198)
at
jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:271)
at
jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:224)
at
jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$InternalReadSubscription.signalReadable(SocketTube.java:675)
at
jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$ReadEvent.signalEvent(SocketTube.java:829)
at
jdk.incubator.httpclient/jdk.incubator.http.SocketTube$SocketFlowEvent.handle(SocketTube.java:243)
at
jdk.incubator.httpclient/jdk.incubator.http.HttpClientImpl$SelectorManager.handleEvent(HttpClientImpl.java:769)
at
jdk.incubator.httpclient/jdk.incubator.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:731)
Process finished with exit code 1
--
If I use a curl to make the request of my (node/express) server, I get:
--
$ curl -v http://localhost:8080/index.html
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /index.html HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Content-Type: text/html; charset=utf-8
< Content-Length: 58
< ETag: W/"3a-EwoPOQKsJivlqZA3z/ulngzMv9U"
< Date: Tue, 15 May 2018 00:18:47 GMT
< Connection: keep-alive
<
* Connection #0 to host localhost left intact
HeadingSome Text
--
Anyone able to tell me what I'm doing wrong?
TIA!
Re:
Daniel: Thanks, it did seem improbable, but seemed to be the only common
factor. But I suspect Joakim's astute observation is more relevant.
I'm running on Linux, not Mac, and t's just a thrown together node.js
server. I guess that means the real bug is probably in node, though one
would think that the Java implementation should be robust enough to at
least not crash (
I'll see if I can a) make it work if I run against say a JAX-RS server, and
b) file an appropriate bug.
Thanks everyone.
On Tue, May 15, 2018 at 5:38 AM Joakim Erdfelt
wrote:
> You're server is reporting the wrong Content-Length.
>
> "HeadingSome Text" is 59
> characters
>
> But the server said "Content-Length: 58"
>
> Also, "Connection: keep-alive" is a HTTP/1.0 concept only, but is being
> reported on your HTTP/1.1 request/response improperly.
>
>
> On Mon, May 14, 2018 at 7:20 PM, Simon Roberts <
> si...@dancingcloudservices.com> wrote:
>
>>
>> I have a very simple attempt to use the Java 10 / incubator httpclient
>> api. It works on "regular" resources, but fails horribly when attempting to
>> get things from localhost. It fails using 127.0.0.1, the actual
>> non-loopback IP, and the name localhost. The server is running, and
>> presenting a very simple web page (I originally tried json, but have since
>> simplified it attempting to find out what's amiss).
>>
>> The code is as simple as I can imagine (and that might be the problem :)
>>
>> --
>> HttpClient client = HttpClient.newHttpClient();
>> URI uri = URI.create("http://192.168.1.102:8080/index.html";);
>>
>> HttpRequest getRequest = HttpRequest.newBuilder()
>> .uri(uri).GET().build();
>>
>> HttpResponse response = client.send(getRequest,
>> HttpResponse.BodyHandler.asString());
>> System.out.println("response to get: " + response.body());
>> --
>>
>> The error prints a long stack trace, which I suppose I must post in its
>> entiretly:
>>
>> --
>>
>> WARNING: Using incubator modules: jdk.incubator.httpclient
>> Exception in thread "main" java.io.EOFException: EOF reached while reading
>> at
>> jdk.incubator.httpclient/jdk.incubator.http.Http1AsyncReceiver$Http1TubeSubscriber.onComplete(Http1AsyncReceiver.java:507)
>> at
>> jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$ReadSubscription.signalCompletion(SocketTube.java:551)
>> at
>> jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$InternalReadSubscription.read(SocketTube.java:728)
>> at
>> jdk.incubator.httpclient/jdk.incubator.http.SocketTube$SocketFlowTask.run(SocketTube.java:171)
>> at
>> jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198)
>> at
>> jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:271)
>> at
>> jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:224)
>> at
>> jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$InternalReadSubscription.signalReadable(SocketTube.java:675)
>> at
>> jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$ReadEvent.signalEvent(SocketTube.java:829)
>> at
>> jdk.incubator.httpclient/jdk.incubator.http.SocketTube$SocketFlowEvent.handle(SocketTube.java:243)
>> at
>> jdk.incubator.httpclient/jdk.incubator.http.HttpClientImpl$SelectorManager.handleEvent(HttpClientImpl.java:769)
>> at
>> jdk.incubator.httpclient/jdk.incubator.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:731)
>>
>> Process finished with exit code 1
>> --
>>
>> If I use a curl to make the request of my (node/express) server, I get:
>>
>> --
>> $ curl -v http://localhost:8080/index.html
>> * Trying 127.0.0.1...
>> * Connected to localhost (127.0.0.1) port 8080 (#0)
>> > GET /index.html HTTP/1.1
>> > Host: localhost:8080
>> > User-Agent: curl/7.47.0
>> > Accept: */*
>> >
>> < HTTP/1.1 200 OK
>> < X-Powered-By: Express
>> < Content-Type: text/html; charset=utf-8
>> < Content-Length: 58
>> < ETag: W/"3a-EwoPOQKsJivlqZA3z/ulngzMv9U"
>> < Date: Tue, 15 May 2018 00:18:47 GMT
>> < Connection: keep-alive
>> <
>> * Connection #0 to host localhost left intact
>> HeadingSome Text
>> --
>>
>> Anyone able to tell me what I'm doing wrong?
>>
>> TIA!
>>
>>
>>
>
--
Simon Roberts
(303) 249 3613
Re:
Ah, wait, the content length thing doesn't seem to be all that certain. I
modified my node server to put a line ending on the output, and it still
reports 59 characters (which is now, presumably correct.) The client still
crashes the same way.
meanwhile, I'll try it with a JAX-RS based server instead.
On Tue, May 15, 2018 at 7:25 AM Simon Roberts <
si...@dancingcloudservices.com> wrote:
> Daniel: Thanks, it did seem improbable, but seemed to be the only common
> factor. But I suspect Joakim's astute observation is more relevant.
>
> I'm running on Linux, not Mac, and t's just a thrown together node.js
> server. I guess that means the real bug is probably in node, though one
> would think that the Java implementation should be robust enough to at
> least not crash (
>
> I'll see if I can a) make it work if I run against say a JAX-RS server,
> and b) file an appropriate bug.
>
> Thanks everyone.
>
>
> On Tue, May 15, 2018 at 5:38 AM Joakim Erdfelt
> wrote:
>
>> You're server is reporting the wrong Content-Length.
>>
>> "HeadingSome Text" is 59
>> characters
>>
>> But the server said "Content-Length: 58"
>>
>> Also, "Connection: keep-alive" is a HTTP/1.0 concept only, but is being
>> reported on your HTTP/1.1 request/response improperly.
>>
>>
>> On Mon, May 14, 2018 at 7:20 PM, Simon Roberts <
>> si...@dancingcloudservices.com> wrote:
>>
>>>
>>> I have a very simple attempt to use the Java 10 / incubator httpclient
>>> api. It works on "regular" resources, but fails horribly when attempting to
>>> get things from localhost. It fails using 127.0.0.1, the actual
>>> non-loopback IP, and the name localhost. The server is running, and
>>> presenting a very simple web page (I originally tried json, but have since
>>> simplified it attempting to find out what's amiss).
>>>
>>> The code is as simple as I can imagine (and that might be the problem :)
>>>
>>> --
>>> HttpClient client = HttpClient.newHttpClient();
>>> URI uri = URI.create("http://192.168.1.102:8080/index.html";);
>>>
>>> HttpRequest getRequest = HttpRequest.newBuilder()
>>> .uri(uri).GET().build();
>>>
>>> HttpResponse response = client.send(getRequest,
>>> HttpResponse.BodyHandler.asString());
>>> System.out.println("response to get: " + response.body());
>>> --
>>>
>>> The error prints a long stack trace, which I suppose I must post in its
>>> entiretly:
>>>
>>> --
>>>
>>> WARNING: Using incubator modules: jdk.incubator.httpclient
>>> Exception in thread "main" java.io.EOFException: EOF reached while
>>> reading
>>> at
>>> jdk.incubator.httpclient/jdk.incubator.http.Http1AsyncReceiver$Http1TubeSubscriber.onComplete(Http1AsyncReceiver.java:507)
>>> at
>>> jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$ReadSubscription.signalCompletion(SocketTube.java:551)
>>> at
>>> jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$InternalReadSubscription.read(SocketTube.java:728)
>>> at
>>> jdk.incubator.httpclient/jdk.incubator.http.SocketTube$SocketFlowTask.run(SocketTube.java:171)
>>> at
>>> jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198)
>>> at
>>> jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:271)
>>> at
>>> jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:224)
>>> at
>>> jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$InternalReadSubscription.signalReadable(SocketTube.java:675)
>>> at
>>> jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$ReadEvent.signalEvent(SocketTube.java:829)
>>> at
>>> jdk.incubator.httpclient/jdk.incubator.http.SocketTube$SocketFlowEvent.handle(SocketTube.java:243)
>>> at
>>> jdk.incubator.httpclient/jdk.incubator.http.HttpClientImpl$SelectorManager.handleEvent(HttpClientImpl.java:769)
>>> at
>>> jdk.incubator.httpclient/jdk.incubator.http.HttpClientImpl$Sel
Re:
Chris, I'm OK with the idea that the program might be "operating in a broken environment" but I find it had to accept the idea that "it's not a crash" as useful. By the time the exception is thrown, I cannot access the data. Merely telling the caller that there was an inconsistency in the server (which I think we're assuming is true) has rendered the data unreachable. Since every other test mechanism at my disposal survives whatever inaccuracy the node server is producing, it seems a bit ... well, let's say "unforgiving" that this code treats it as an unrecoverable failure. On Tue, May 15, 2018 at 7:31 AM Chris Hegarty wrote: > Simon, > > > On 15 May 2018, at 14:25, Simon Roberts > wrote: > > > > ... > > I'm running on Linux, not Mac, and t's just a thrown together node.js > server. I guess that means the real bug is probably in node, though one > would think that the Java implementation should be robust enough to at > least not crash ( > > To be clear, this is NOT a crash ( in Java terms ). > > The exception, " java.io.EOFException: EOF reached while reading”, > that you are seeing is conveying the message that and unexpected > end-of-file(stream) has been reached while received data. This > appears to be correct as per Joacim’s observation. > > Silently ignoring, or otherwise not reporting, the unexpected EOF, > would be incorrect and considered a bug. > > -Chris. -- Simon Roberts (303) 249 3613
Re:
If I understand you correctly, you are saying that the "simple" version of
the code-code by the way that the project's main web page presents as it's
first example--is so simple that it's actually unusable in any production
scenario. I know I cannot use code for production that fails to read any
data from a (presumably) merely mis-configured server (a server from which
all other tools successfully read data. Did I interpret correctly, or did I
miss something? If correctly, I'd be surprised if that doesn't strike you
as sub-optimal to the point your pride in your work would want to make it
more usable.
It doesn't seem inappropriate to report a "warning" situation using an
exception? Would not an aggregate return that includes data, headers,
status code, ... and warnings be more helpful in this case? Mis-configured
servers (assuming that's the cause) are not uncommon around the web.
But perhaps more importantly, whatever the problem is, it is not fixed by
your code. The error is actually thrown by the *send* call, as I've now
determined as a result of trying your code. (I modified it very slightly so
as to complete it, and catch the exception.)
public static void main(String[] args) /*throws Throwable */ {
HttpClient client = HttpClient.newHttpClient();
URI uri = URI.create("http://192.168.1.102:8080/index.html";);
HttpRequest getRequest = HttpRequest.newBuilder()
.uri(uri)
.GET()
.build();
try {
HttpResponse response = client.send(getRequest,
HttpResponse.BodyHandler.asInputStream());
System.out.println("response: " + response);
response.headers().firstValue("content-length")
.ifPresent(cl -> System.out.println("content-length:" + cl));
InputStream is = response.body();
byte[] bytes = new byte[64 * 1024];
int read = 0, count;
try {
while ((count = is.read(bytes, read, bytes.length - read)) != -1)
read += count;
} catch (IOException e) {
System.err.println("Ignoring " + e);
}
System.out.println("bytes read: " + read);
String bodyAsString = new String(bytes, StandardCharsets.UTF_8);
System.out.println("body: " + bodyAsString);
} catch (Throwable t) {
System.out.println("Bang: ");
t.printStackTrace();
}
}
the output follows (note, this is the *entire* output from the program. So
far as I can see, there is no mention of my code in the exception stack
trace (which seems to be a mistake in itself, as it's rather hard to track
down where an error occurred if it's not even mentioned in the trace). I
for my part will turn my attention to getting going with a different server:
/usr/local/jdk-10.0.1/bin/java
-javaagent:/home/simon/idea/idea-IC-181.4445.78/lib/idea_rt.jar=40188:/home/simon/idea/idea-IC-181.4445.78/bin
-Dfile.encoding=UTF-8 -p /home/simon/IdeaProjects/tentest/target/classes -m
tentest/httpstuff.Smartass
WARNING: Using incubator modules: jdk.incubator.httpclient
Bang:
java.io.EOFException: EOF reached while reading
at
jdk.incubator.httpclient/jdk.incubator.http.Http1AsyncReceiver$Http1TubeSubscriber.onComplete(Http1AsyncReceiver.java:507)
at
jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$ReadSubscription.signalCompletion(SocketTube.java:551)
at
jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$InternalReadSubscription.read(SocketTube.java:728)
at
jdk.incubator.httpclient/jdk.incubator.http.SocketTube$SocketFlowTask.run(SocketTube.java:171)
at
jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198)
at
jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:271)
at
jdk.incubator.httpclient/jdk.incubator.http.internal.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:224)
at
jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$InternalReadSubscription.signalReadable(SocketTube.java:675)
at
jdk.incubator.httpclient/jdk.incubator.http.SocketTube$InternalReadPublisher$ReadEvent.signalEvent(SocketTube.java:829)
at
jdk.incubator.httpclient/jdk.incubator.http.SocketTube$SocketFlowEvent.handle(SocketTube.java:243)
at
jdk.incubator.httpclient/jdk.incubator.http.HttpClientImpl$SelectorManager.handleEvent(HttpClientImpl.java:769)
at
jdk.incubator.httpclient/jdk.incubator.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:731)
Process finished with exit code 0
On Tue, May 15, 2018 at 8:38 AM Chris Hegarty
wrote:
> Simon,
>
> > On 15 May 2018, at 14:47, Simon Roberts
> wrote:
> >
> > Chris, I'm OK with the idea that the program might be "operating in a
> broken environment”
>
> You may be
EOF excption in HTTP 1.1 server interaction
(Added subject line, sorry, not sure how I missed that in the first place!)
I can pretty much confirm this has nothing to do with content length. I
wrote the code below to allow experimentation and even as it stands, which
I believe has a correct content length, and a bunch of other stuff removed
from the response) the client still fails. I also tried it with various
combinations of the response lines commented out, and all of them present,
failure every time.
If you'd like to suggest the combination that "should" work, I'd be happy
to try it of course.
public final class Main {
public static final String[] response = {
"HTTP/1.1 200 OK",
// "X-Powered-By: Express",
// "Content-Type: text/html; charset=utf-8",
"Content-Length: 58",
// "ETag: W/\"3a-EwoPOQKsJivlqZA3z/ulngzMv9U\"",
// "Date: Tue, 15 May 2018 00:18:47 GMT",
// "Connection: keep-alive",
"",
"HeadingSome Text",
"",
""
};
public static void main(String[] args) throws Throwable {
var ss = new ServerSocket(8080);
var s = ss.accept();
var in = new BufferedReader(new InputStreamReader(s.getInputStream()));
String line;
while ((line = in.readLine()) != null) {
System.out.println("< " + line);
if ("".equals(line)) break;
}
var out = new PrintWriter(new OutputStreamWriter(s.getOutputStream()));
for (var st : response) {
out.println(st);
System.out.println("> " + st);
}
out.flush();
s.close();
}
}
On Tue, May 15, 2018 at 9:46 AM Chris Hegarty
wrote:
> Simon,
>
> Only a partial reply, I’ll reply with other details later.
>
> > On 15 May 2018, at 16:10, Simon Roberts
> wrote:
> >
> > If I understand you correctly, you are saying that the "simple" version
> of the code-code by the way that the project's main web page presents as
> it's first example--is so simple that it's actually unusable in any
> production scenario.
>
> That is not what I am saying. What I am saying is that the String handler
> is a convenience handler that buffers all the response data and returns it
> once decoded. In some circumstances it is just not possible to return, as a
> String, the response data, if the server behaves incorrectly. In the
> scenario you are encountering it appears that the server is returning too
> little data. It may not be possible to always decode this partial data. And
> even if you do decode this partial data, something further up the stack is
> likely to fail, if parsing JSON for example.
>
> My point is that if you want fault tolerance in the case of a misbehaving
> server there are other ways to achieve that.
>
> > I know I cannot use code for production that fails to read any data from
> a (presumably) merely mis-configured server (a server from which all other
> tools successfully read data.
>
> What do you hope to do with partial data read from the server? If it’s
> JSON can you decode it, or a gif can you display it?
>
> > Did I interpret correctly, or did I miss something? If correctly, I'd be
> surprised if that doesn't strike you as sub-optimal to the point your pride
> in your work would want to make it more usable.
>
> We do have pride in our work. I am engaging here to try to help you.
>
> > It doesn't seem inappropriate to report a "warning" situation using an
> exception? Would not an aggregate return that includes data, headers,
> status code, ... and warnings be more helpful in this case?
>
> There are other ways to achieve that, but IMO doing so for the String
> handler would not be helpful to the vast majority of Java developers, that
> would not check the carried warning.
>
> > Mis-configured servers (assuming that's the cause) are not uncommon
> around the web.
>
> Sure, but many clients will not be able to operate correctly with such,
> it’s a matter of where and how they fail.
>
> > But perhaps more importantly, whatever the problem is, it is not fixed
> by your code. The error is actually thrown by the *send* call, as I've now
> determined as a result of trying your code. (I modified it very slightly so
> as to complete it, and catch the exception.)
>
> D’oh! Apologies, that’s what I get for sending something without testing
> it more carefully, but you seem to have gotten past it.
>
> -Chris
--
Simon Roberts
(303) 249 3613
Re: EOF excption in HTTP 1.1 server interaction
Thanks for the clarification; as I mentioned, I tried a number of
variations, with and without the "excess" empty lines. I also copied the
output from a curl session with a server that provides a successful
interaction with the client (so the content length etc were all correct).
In every case the *send* failed regardless. I'm finding myself inclined to
believe that something about the way the upgrade to 2.0 request is being
handled is relevant. That said, I'm unsure what line endings I'm sending in
my fake server, but I'm running on Linux, not windows (perhaps that's your
point).
So that we can finally put to bed one way or the other the suggestion that
this is the server-side's fault, perhaps you could indicate an exact
(minimal) string, that you believe should work in my fake-server? I'm not
an expert in the HTTP specification, so it could be pretty inefficient to
keep cycling round this loop ;)
On Tue, May 15, 2018 at 12:16 PM Bernd Eckenfels
wrote:
> Your example code writes 2 (emp5) lines more than the Content-Length
> includes. You should also use crlf for the end of http headers (Sample
> works only on Windows)ö
>
> Gruss
> Bernd
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> --
> *From:* net-dev on behalf of Simon
> Roberts
> *Sent:* Tuesday, May 15, 2018 7:22:27 PM
> *To:* net-dev@openjdk.java.net
> *Subject:* EOF excption in HTTP 1.1 server interaction
>
> (Added subject line, sorry, not sure how I missed that in the first place!)
>
> I can pretty much confirm this has nothing to do with content length. I
> wrote the code below to allow experimentation and even as it stands, which
> I believe has a correct content length, and a bunch of other stuff removed
> from the response) the client still fails. I also tried it with various
> combinations of the response lines commented out, and all of them present,
> failure every time.
>
> If you'd like to suggest the combination that "should" work, I'd be happy
> to try it of course.
>
> public final class Main {
> public static final String[] response = {
> "HTTP/1.1 200 OK",
> // "X-Powered-By: Express",
> // "Content-Type: text/html; charset=utf-8",
> "Content-Length: 58",
> // "ETag: W/\"3a-EwoPOQKsJivlqZA3z/ulngzMv9U\"",
> // "Date: Tue, 15 May 2018 00:18:47 GMT",
> // "Connection: keep-alive",
> "",
> "HeadingSome Text",
> "",
> ""
> };
>
> public static void main(String[] args) throws Throwable {
> var ss = new ServerSocket(8080);
> var s = ss.accept();
> var in = new BufferedReader(new InputStreamReader(s.getInputStream()));
> String line;
> while ((line = in.readLine()) != null) {
> System.out.println("< " + line);
> if ("".equals(line)) break;
> }
> var out = new PrintWriter(new OutputStreamWriter(s.getOutputStream()));
> for (var st : response) {
> out.println(st);
> System.out.println("> " + st);
> }
> out.flush();
> s.close();
>
> }
> }
>
>
> On Tue, May 15, 2018 at 9:46 AM Chris Hegarty
> wrote:
>
>> Simon,
>>
>> Only a partial reply, I’ll reply with other details later.
>>
>> > On 15 May 2018, at 16:10, Simon Roberts
>> wrote:
>> >
>> > If I understand you correctly, you are saying that the "simple" version
>> of the code-code by the way that the project's main web page presents as
>> it's first example--is so simple that it's actually unusable in any
>> production scenario.
>>
>> That is not what I am saying. What I am saying is that the String handler
>> is a convenience handler that buffers all the response data and returns it
>> once decoded. In some circumstances it is just not possible to return, as a
>> String, the response data, if the server behaves incorrectly. In the
>> scenario you are encountering it appears that the server is returning too
>> little data. It may not be possible to always decode this partial data. And
>> even if you do decode this partial data, something further up the stack is
>> likely to fail, if parsing JSON for example.
>>
>> My point is that if you want fault tolerance in the case of a misbehaving
>> server there are other ways to achieve that.
>>
>> > I know I cannot use code for production that fails to read any data
>> from a (presumably) merely mis-configured server (a server from which all
>> other tools
Re: EOF excption in HTTP 1.1 server interaction
I have further tweeked my "fake server" so that it should respond with CRLF
at line endings, and tried it with content lengths of 58, 59, and 60.
Regardless, the httpdlient fails *on the call to send* with each of these
experiments. Are there any additional tests or variations that people
suggest trying?
It seems to me that one of the things that's different between the severs
that the httpClient likes, and the ones it doesnt, is that I'm pretty sure
that the ones it doesn't like utterly ignore the HTTP2 upgrade request.
public static final String[] response = {
"HTTP/1.1 200 OK",
"Content-Type: text/html; charset=utf-8",
"Content-Length: 60",
"",
"HeadingSome Text",
};
public static void main(String[] args) throws Throwable {
var ss = new ServerSocket(8080);
var s = ss.accept();
var in = new BufferedReader(new InputStreamReader(s.getInputStream()));
String line;
while ((line = in.readLine()) != null) {
System.out.println("< " + line);
if ("".equals(line)) break;
}
var out = new PrintWriter(new OutputStreamWriter(s.getOutputStream()));
for (var st : response) {
out.print(st + "0x000D0x000A");
System.out.println("> " + st);
}
out.flush();
s.close();
On Tue, May 15, 2018 at 12:44 PM Simon Roberts <
si...@dancingcloudservices.com> wrote:
> Thanks for the clarification; as I mentioned, I tried a number of
> variations, with and without the "excess" empty lines. I also copied the
> output from a curl session with a server that provides a successful
> interaction with the client (so the content length etc were all correct).
> In every case the *send* failed regardless. I'm finding myself inclined to
> believe that something about the way the upgrade to 2.0 request is being
> handled is relevant. That said, I'm unsure what line endings I'm sending in
> my fake server, but I'm running on Linux, not windows (perhaps that's your
> point).
>
> So that we can finally put to bed one way or the other the suggestion that
> this is the server-side's fault, perhaps you could indicate an exact
> (minimal) string, that you believe should work in my fake-server? I'm not
> an expert in the HTTP specification, so it could be pretty inefficient to
> keep cycling round this loop ;)
>
>
>
> On Tue, May 15, 2018 at 12:16 PM Bernd Eckenfels
> wrote:
>
>> Your example code writes 2 (emp5) lines more than the Content-Length
>> includes. You should also use crlf for the end of http headers (Sample
>> works only on Windows)ö
>>
>> Gruss
>> Bernd
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> --
>> *From:* net-dev on behalf of Simon
>> Roberts
>> *Sent:* Tuesday, May 15, 2018 7:22:27 PM
>> *To:* net-dev@openjdk.java.net
>> *Subject:* EOF excption in HTTP 1.1 server interaction
>>
>> (Added subject line, sorry, not sure how I missed that in the first
>> place!)
>>
>> I can pretty much confirm this has nothing to do with content length. I
>> wrote the code below to allow experimentation and even as it stands, which
>> I believe has a correct content length, and a bunch of other stuff removed
>> from the response) the client still fails. I also tried it with various
>> combinations of the response lines commented out, and all of them present,
>> failure every time.
>>
>> If you'd like to suggest the combination that "should" work, I'd be happy
>> to try it of course.
>>
>> public final class Main {
>> public static final String[] response = {
>> "HTTP/1.1 200 OK",
>> // "X-Powered-By: Express",
>> // "Content-Type: text/html; charset=utf-8",
>> "Content-Length: 58",
>> // "ETag: W/\"3a-EwoPOQKsJivlqZA3z/ulngzMv9U\"",
>> // "Date: Tue, 15 May 2018 00:18:47 GMT",
>> // "Connection: keep-alive",
>> "",
>> "HeadingSome Text",
>> "",
>> ""
>> };
>>
>> public static void main(String[] args) throws Throwable {
>> var ss = new ServerSocket(8080);
>> var s = ss.accept();
>> var in = new BufferedReader(new
>> InputStreamReader(s.getInputStream()));
>> String line;
>> while ((line = in.readLine()) != null) {
>> System.out.println("< " + line);
>> if ("".equals(line)) break;
>>
Re: EOF excption in HTTP 1.1 server interaction
Wooops, bran failure. JLS 3.10.4 :( Will fix to use \r\n and get back...
On Tue, May 15, 2018 at 1:43 PM Bernd Eckenfels
wrote:
> Try using out.print(st+“\n\r“); instead. (And Account for the extra bytes
> in the body as well or output the last string without the EOLs.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> --
> *From:* net-dev on behalf of Simon
> Roberts
> *Sent:* Tuesday, May 15, 2018 8:44:08 PM
> *To:* net-dev@openjdk.java.net
> *Subject:* Re: EOF excption in HTTP 1.1 server interaction
>
> Thanks for the clarification; as I mentioned, I tried a number of
> variations, with and without the "excess" empty lines. I also copied the
> output from a curl session with a server that provides a successful
> interaction with the client (so the content length etc were all correct).
> In every case the *send* failed regardless. I'm finding myself inclined to
> believe that something about the way the upgrade to 2.0 request is being
> handled is relevant. That said, I'm unsure what line endings I'm sending in
> my fake server, but I'm running on Linux, not windows (perhaps that's your
> point).
>
> So that we can finally put to bed one way or the other the suggestion that
> this is the server-side's fault, perhaps you could indicate an exact
> (minimal) string, that you believe should work in my fake-server? I'm not
> an expert in the HTTP specification, so it could be pretty inefficient to
> keep cycling round this loop ;)
>
>
>
> On Tue, May 15, 2018 at 12:16 PM Bernd Eckenfels
> wrote:
>
>> Your example code writes 2 (emp5) lines more than the Content-Length
>> includes. You should also use crlf for the end of http headers (Sample
>> works only on Windows)ö
>>
>> Gruss
>> Bernd
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> --
>> *From:* net-dev on behalf of Simon
>> Roberts
>> *Sent:* Tuesday, May 15, 2018 7:22:27 PM
>> *To:* net-dev@openjdk.java.net
>> *Subject:* EOF excption in HTTP 1.1 server interaction
>>
>> (Added subject line, sorry, not sure how I missed that in the first
>> place!)
>>
>> I can pretty much confirm this has nothing to do with content length. I
>> wrote the code below to allow experimentation and even as it stands, which
>> I believe has a correct content length, and a bunch of other stuff removed
>> from the response) the client still fails. I also tried it with various
>> combinations of the response lines commented out, and all of them present,
>> failure every time.
>>
>> If you'd like to suggest the combination that "should" work, I'd be happy
>> to try it of course.
>>
>> public final class Main {
>> public static final String[] response = {
>> "HTTP/1.1 200 OK",
>> // "X-Powered-By: Express",
>> // "Content-Type: text/html; charset=utf-8",
>> "Content-Length: 58",
>> // "ETag: W/\"3a-EwoPOQKsJivlqZA3z/ulngzMv9U\"",
>> // "Date: Tue, 15 May 2018 00:18:47 GMT",
>> // "Connection: keep-alive",
>> "",
>> "HeadingSome Text",
>> "",
>> ""
>> };
>>
>> public static void main(String[] args) throws Throwable {
>> var ss = new ServerSocket(8080);
>> var s = ss.accept();
>> var in = new BufferedReader(new
>> InputStreamReader(s.getInputStream()));
>> String line;
>> while ((line = in.readLine()) != null) {
>> System.out.println("< " + line);
>> if ("".equals(line)) break;
>> }
>> var out = new PrintWriter(new
>> OutputStreamWriter(s.getOutputStream()));
>> for (var st : response) {
>> out.println(st);
>> System.out.println("> " + st);
>> }
>> out.flush();
>> s.close();
>>
>> }
>> }
>>
>>
>> On Tue, May 15, 2018 at 9:46 AM Chris Hegarty
>> wrote:
>>
>>> Simon,
>>>
>>> Only a partial reply, I’ll reply with other details later.
>>>
>>> > On 15 May 2018, at 16:10, Simon Roberts <
>>> si...@dancingcloudservices.com> wrote:
>>> >
>>> > If I understand you correctly, you are saying that the "simple"
>>> version of the code-code by the way that the project's main web page
>>> presents as it's first example
Re: EOF excption in HTTP 1.1 server interaction
Well, I give up. I'ts something to do with nodejs (which would seem like a
popular enough server to be of interest, but whatever) and perhaps the way
that node responds when asked to perform an HTTP2.0 upgrade.
Node generated a response that caused httpClient to fail. I used curl to
try to extract that response and pasted it into my "fake server". The
response from my fake server works. Of course, the one remaining difference
is that I cannot tell how node might be reacting to the upgrade request,
since curl didn't issue that part of the request. So, I think the problem
is there.
public static final String[] response = {
"HTTP/1.1 200 OK",
"X-Powered-By: Expressd",
"Content-Type: text/html; charset=utf-8",
"Content-Length: 60",
"ETag: W/\"3c-CQHFqoSATSxoI5iZHLfu5OeEG3k\"",
"Date: Tue, 15 May 2018 20:34:49 GMT",
"Connection: keep-alive",
"",
"",
"HeadingSome Text",
""
};
public static void main(String[] args) throws Throwable {
var ss = new ServerSocket(8080);
var s = ss.accept();
var in = new BufferedReader(new InputStreamReader(s.getInputStream()));
String line;
while ((line = in.readLine()) != null) {
System.out.println("< " + line);
if ("".equals(line)) break;
}
var out = new PrintWriter(new OutputStreamWriter(s.getOutputStream()));
for (var st : response) {
out.print(st + "\r\n");
System.out.println("> " + st);
}
out.flush();
s.close();
}
}
On Tue, May 15, 2018 at 1:55 PM Simon Roberts <
si...@dancingcloudservices.com> wrote:
> Wooops, bran failure. JLS 3.10.4 :( Will fix to use \r\n and get back...
>
>
> On Tue, May 15, 2018 at 1:43 PM Bernd Eckenfels
> wrote:
>
>> Try using out.print(st+“\n\r“); instead. (And Account for the extra bytes
>> in the body as well or output the last string without the EOLs.
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> --
>> *From:* net-dev on behalf of Simon
>> Roberts
>> *Sent:* Tuesday, May 15, 2018 8:44:08 PM
>> *To:* net-dev@openjdk.java.net
>> *Subject:* Re: EOF excption in HTTP 1.1 server interaction
>>
>> Thanks for the clarification; as I mentioned, I tried a number of
>> variations, with and without the "excess" empty lines. I also copied the
>> output from a curl session with a server that provides a successful
>> interaction with the client (so the content length etc were all correct).
>> In every case the *send* failed regardless. I'm finding myself inclined to
>> believe that something about the way the upgrade to 2.0 request is being
>> handled is relevant. That said, I'm unsure what line endings I'm sending in
>> my fake server, but I'm running on Linux, not windows (perhaps that's your
>> point).
>>
>> So that we can finally put to bed one way or the other the suggestion
>> that this is the server-side's fault, perhaps you could indicate an exact
>> (minimal) string, that you believe should work in my fake-server? I'm not
>> an expert in the HTTP specification, so it could be pretty inefficient to
>> keep cycling round this loop ;)
>>
>>
>>
>> On Tue, May 15, 2018 at 12:16 PM Bernd Eckenfels
>> wrote:
>>
>>> Your example code writes 2 (emp5) lines more than the Content-Length
>>> includes. You should also use crlf for the end of http headers (Sample
>>> works only on Windows)ö
>>>
>>> Gruss
>>> Bernd
>>>
>>> Gruss
>>> Bernd
>>> --
>>> http://bernd.eckenfels.net
>>> --
>>> *From:* net-dev on behalf of Simon
>>> Roberts
>>> *Sent:* Tuesday, May 15, 2018 7:22:27 PM
>>> *To:* net-dev@openjdk.java.net
>>> *Subject:* EOF excption in HTTP 1.1 server interaction
>>>
>>> (Added subject line, sorry, not sure how I missed that in the first
>>> place!)
>>>
>>> I can pretty much confirm this has nothing to do with content length. I
>>> wrote the code below to allow experimentation and even as it stands, which
>>> I believe has a correct content length, and a bunch of other stuff removed
>>> from the response) the client still fails. I also tried it with various
>>> combinations of the response lines commented out, and all of them present,
>>> failure every time.
>>>
>>> If you'd like to suggest the combination that
Re: EOF excption in HTTP 1.1 server interaction
No, HTTP 2.0 is not supported by nodejs (... current LTS release,
eight-dot-something) and by my fake server. I believe that there might be
something about the way that node is doing that ignoring that's causing the
problem.
If there's an easy way for me to dump the entire transaction, and anyone
cares why the send request fails (this thing **never calls the
BodyHandler** in case I've not made that clear) then I'm happy to run one
more test, if it helps. I guess if anyone would like to see it, I can
install wireshark. Let me know if you want me to do that. (And to be clear,
this is now for the benefit of anyone *else* who wants to pursue this, not
for me, I'm gong to continue learning this API against a server that it
likes.
On Tue, May 15, 2018 at 3:17 PM Bernd Eckenfels
wrote:
> When you talk about HTT/2.0 Upgrades, do you also deal with TLS? You can
> use a network tracer instead of curl to debug the whole exchange.
>
> But you might need to turn on TLS debug to dump the session key (so the
> protocol analyser like wireshark can actually decrypt it)
>
> BTW you added one empty line too much in your Simulator Server now, so
> it’s 62 bytes.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ----------
> *From:* net-dev on behalf of Simon
> Roberts
> *Sent:* Tuesday, May 15, 2018 10:47:35 PM
> *To:* net-dev@openjdk.java.net
> *Subject:* Re: EOF excption in HTTP 1.1 server interaction
>
> Well, I give up. I'ts something to do with nodejs (which would seem like a
> popular enough server to be of interest, but whatever) and perhaps the way
> that node responds when asked to perform an HTTP2.0 upgrade.
>
> Node generated a response that caused httpClient to fail. I used curl to
> try to extract that response and pasted it into my "fake server". The
> response from my fake server works. Of course, the one remaining difference
> is that I cannot tell how node might be reacting to the upgrade request,
> since curl didn't issue that part of the request. So, I think the problem
> is there.
>
> public static final String[] response = {
> "HTTP/1.1 200 OK",
> "X-Powered-By: Expressd",
> "Content-Type: text/html; charset=utf-8",
> "Content-Length: 60",
> "ETag: W/\"3c-CQHFqoSATSxoI5iZHLfu5OeEG3k\"",
> "Date: Tue, 15 May 2018 20:34:49 GMT",
> "Connection: keep-alive",
> "",
> "",
> "HeadingSome Text",
> ""
> };
>
> public static void main(String[] args) throws Throwable {
> var ss = new ServerSocket(8080);
> var s = ss.accept();
> var in = new BufferedReader(new InputStreamReader(s.getInputStream()));
> String line;
> while ((line = in.readLine()) != null) {
> System.out.println("< " + line);
> if ("".equals(line)) break;
> }
> var out = new PrintWriter(new OutputStreamWriter(s.getOutputStream()));
> for (var st : response) {
> out.print(st + "\r\n");
> System.out.println("> " + st);
> }
> out.flush();
> s.close();
> }
> }
>
> On Tue, May 15, 2018 at 1:55 PM Simon Roberts <
> si...@dancingcloudservices.com> wrote:
>
>> Wooops, bran failure. JLS 3.10.4 :( Will fix to use \r\n and get back...
>>
>>
>> On Tue, May 15, 2018 at 1:43 PM Bernd Eckenfels
>> wrote:
>>
>>> Try using out.print(st+“\n\r“); instead. (And Account for the extra
>>> bytes in the body as well or output the last string without the EOLs.
>>>
>>> Gruss
>>> Bernd
>>> --
>>> http://bernd.eckenfels.net
>>> --
>>> *From:* net-dev on behalf of Simon
>>> Roberts
>>> *Sent:* Tuesday, May 15, 2018 8:44:08 PM
>>> *To:* net-dev@openjdk.java.net
>>> *Subject:* Re: EOF excption in HTTP 1.1 server interaction
>>>
>>> Thanks for the clarification; as I mentioned, I tried a number of
>>> variations, with and without the "excess" empty lines. I also copied the
>>> output from a curl session with a server that provides a successful
>>> interaction with the client (so the content length etc were all correct).
>>> In every case the *send* failed regardless. I'm finding myself inclined to
>>> believe that something about the way the upgrade to 2.0 request is being
>>> handled is relevant. That said, I'm unsure what line endings I'm sending in
>>> my fake server, but I'm running on Linux, not windows (
Re: EOF excption in HTTP 1.1 server interaction
Thanks for investigating this, Chris. I will put together a trivial node server and instructions on how to set it up (it's delightfully simple) Should be much less than an hour, if I can give it my un-distracted attention... On Wed, May 16, 2018 at 8:58 AM Chris Hegarty wrote: > Bernd, > > > On 16 May 2018, at 00:43, Bernd Eckenfels > 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. -- Simon Roberts (303) 249 3613
Re: EOF excption in HTTP 1.1 server interaction
OK, here goes. 1) install node 8.11 from here: https://nodejs.org/ this should consist (though I could be wrong for mac or windows!) of expanding the archive, and adding the contained 'bin' directory to your path. You should be able to execute the commands: node --version (note two minus-signs. Should report v8.11.??) and npm -version (note single minus sign! Might report 5.6?? but might be older, not a big deal) 2) clone this: https://github.com/SimonHGR/RESTserver.git 3) in the resulting directory (RESTserver) enter: npm install (it'll download a bunch of javascript libraries) 4) still in the same directory enter: npm start (it should report Express listening on port 8080) You should now be able to do curl -v http://localhost:8080/simple.html and see: * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 8080 (#0) > GET /simple.html HTTP/1.1 > Host: localhost:8080 > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 200 OK < X-Powered-By: Express < Content-Type: text/html; charset=utf-8 < Content-Length: 95 < ETag: W/"5f-zPY21XEeilaiEZvppUEI+1JlLE8" < Date: Wed, 16 May 2018 16:15:35 GMT < Connection: keep-alive < A Heading A paragraph * Connection #0 to host localhost left intact 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. 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!?) 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. I'll also note that when trying my "trivial serer", it reproduced the problem when it was sending the wrong line-endings. Anyway, hopefully you can look at the protocol exchange and see what node is doing that's wrong. If you need any updates to the node server, just holler, I'll be around and able to put a few minutes into this here and there most of today (at least up through 3pm Mountain time). Cheers On Wed, May 16, 2018 at 9:49 AM Simon Roberts < si...@dancingcloudservices.com> wrote: > Thanks for investigating this, Chris. I will put together a trivial node > server and instructions on how to set it up (it's delightfully simple) > Should be much less than an hour, if I can give it my un-distracted > attention... > > On Wed, May 16, 2018 at 8:58 AM Chris Hegarty > wrote: > >> Bernd, >> >> > On 16 May 2018, at 00:43, Bernd Eckenfels >> 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. > > > > -- > Simon Roberts > (303) 249 3613 > > -- Simon Roberts (303) 249 3613
OT? reactive streams
Hi, apologies for the rather off topic inquiry, but I'm trying to find out more about the reactive streams features that are used inside the new httpClient. I tried to subscribe to what I think is the appropriate list but appeared to hit a "bug in mailman" (three times, so not, apparently, transient). I'm hoping to discover if there are samples, examples, whatever for the streams features (I was successful in implementing a crude BodyHandler / BodySubscriber, so the basics make sense. In particular, this feels like there might be Processors that perform map/flatmap/filter operations, prebuilt for ease of use Also, it feels like there might be examples or tools imteracting with GUI comonents, or perhaps performing infinite series math, like sieve of Erastothanes (sp!?) or the Pi approximation series. Can anyone tell me if they know of any such resources for learning/tinkering? Thanks! -- Simon Roberts (303) 249 3613
Re: EOF excption in HTTP 1.1 server interaction
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 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
