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:
src/jdk.net/
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 points
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
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
https://bugreport.ja
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, Simo
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 tha
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 no
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 inst
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 (w
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 crash" as useful.
A recoverable
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
da
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
(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
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
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 t
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
> --
>
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
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 li
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
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), it
20 matches
Mail list logo
