Re: EOF excption in HTTP 1.1 server interaction

Hello Simon, I am also just a user here, but I certainly agree with you that the sample Code should be able to communicate with (well behaved) public web Servers. So if no TLS or htttp2 is involved, I dont think this is the Problem here. The following is a test Server I used (baed on yours),

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

Re: EOF excption in HTTP 1.1 server interaction

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

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

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.

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

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

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

Re:

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

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

Re:

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 ok with that, but many folk will not. > but I find it had to accept the idea that "it's not a

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

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

Re:

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

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

Re:

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,

Re:

Hi Simon, We are using localhost/127.0.0.1 in all our tests so I doubt this is the problem here. It's difficult to say what is happening with just the stack trace. If you're on Mac that could be an issue with the system proxy configuration. Could you please log a bug through

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

On Tuesday 15 May 2018 03:13 PM, Alan Bateman wrote: On 15/05/2018 08:35, Langer, Christoph wrote: I’m asking because I’m planning to add some AIX options and will have to choose a name for this implementation eventually. @Alan: What do you think? Yes, I agree it should be renamed. Vyom

Re: RFR:8194298 Add support for per Socket configuration of TCP keepalive

On 15/05/2018 08:35, Langer, Christoph wrote: I’m asking because I’m planning to add some AIX options and will have to choose a name for this implementation eventually. @Alan: What do you think? Yes, I agree it should be renamed. Vyom has just finalized the CSR so I assume the final

RE: RFR:8194298 Add support for per Socket configuration of TCP keepalive

Hi, As I had written previously, I’m still unclear whether the naming of the MacOS implementation files is the best choice. Currently it is: src/jdk.net/macosx/classes/jdk/net/UnixSocketOptions.java src/jdk.net/macosx/native/libextnet/UnixSocketOptions.c Maybe it should rather be: