Hi Bernd,
When we added these socket options to JDK, that time these options were not
available on Windows.
Thanks,
Vyom
On Fri, Jun 26, 2020 at 7:12 AM Bernd Eckenfels
wrote:
> Hello,
>
> This would be a great addition. I do not understand why it does not
> support the options available for
Hi,
On Thu, 2020-06-25 at 23:55 +, Bernd Eckenfels wrote:
> This would be a great addition.
Thanks.
> I do not understand why it does not support the options available for
> Windows. Especially given the fact that it actually implements 6
> native methods to print "Unsupported".
>
> But I g
Hi Severin,
Overall code changes looks ok to me, I build & tested at my local REL it
worked fine for me.
Below are few minor comments.
1-> Net.java
1.1-> I think you don't need to explicitly convert value to integer and
then pass it. You can avoid the local int variable creation as follows.
Hello,
Request to have my fix reviewed for issue:
JDK-8247675 : WebSocket can loose the URL encoding of URI query parameters
The fix updates the jdk.internal.net.http.websocket.OpeningHandshake
to ensure that the URL is not reencoded/decoded and loose the original
encoding
Issue: https://bug
Hello,
Request to have my fix reviewed for issue:
JDK-8245245 : WebSocket can loose the URL encoding of URI query parameters
The fix updates the jdk.internal.net.http.websocket.OpeningHandshake
to ensure that the URL is not reencoded/decoded and loose the original
encoding
Issue: https://bu
Rahul,
Won't that start retaining the URL fragment? From
https://tools.ietf.org/html/rfc6455#section-3
Fragment identifiers are meaningless in the context of WebSocket URIs
and MUST NOT be used on these URIs. As with any URI scheme, the
character "#", when not indicating the start of a
> On 26 Jun 2020, at 15:10, Pavel Rappo wrote:
>
> Chris,
>
> Currently (i.e. before the proposed change has been applied) the fragment is
> NOT retained. This is because of the requirement of the mentioned RFC
> section. The proposed change seems to overlook that detail. Hence, my
> quest
Pavel,
That scenario is already handled, the existing behavior is if there is a
fragment, an exception is thrown.
That hasn't changed.
344 private static URI checkURI(URI uri) {
345 String scheme = uri.getScheme();
346 if (!("ws".equalsIgnoreCase(scheme) ||
"wss".equals
> On 26 Jun 2020, at 14:38, Pavel Rappo wrote:
>
> Rahul,
>
> Won't that start retaining the URL fragment? From
> https://tools.ietf.org/html/rfc6455#section-3
>
> Fragment identifiers are meaningless in the context of WebSocket URIs
> and MUST NOT be used on these URIs. As with any UR
I concur. Rahul has convinced me.
Rahul also pointed me to a test that verifies that the IAE is
thrown, so I believe that
http://cr.openjdk.java.net/~ryadav/webrev_8245245/index.html
is good.
best regards,
-- daniel
On 26/06/2020 16:42, Rahul Yadav wrote:
Pavel,
That scenario is already handl
Chris,
Currently (i.e. before the proposed change has been applied) the fragment is
NOT retained. This is because of the requirement of the mentioned RFC section.
The proposed change seems to overlook that detail. Hence, my question.
-Pavel
> On 26 Jun 2020, at 14:51, Chris Hegarty wrote:
>
Looks good to me.
P.S. I think I began to forget the very code I wrote.
> On 26 Jun 2020, at 18:18, Daniel Fuchs wrote:
>
> I concur. Rahul has convinced me.
> Rahul also pointed me to a test that verifies that the IAE is
> thrown, so I believe that
> http://cr.openjdk.java.net/~ryadav/webrev_8
On 26/06/2020 05:17, Vyom Tiwari wrote:
Hi Daniel/Alan,
Please find the latest
webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.6/index.html).
I think we can do better than one signal after 200ms. Have you given any
thought to have a thread that signals many times so that you have a
13 matches
Mail list logo
