Re: RFR: 8209178: Proxied HttpsURLConnection doesn't send BODY when retrying POST request

Hi Julia,   Fix looks good to me, i tested the fix it worked for us.   Thanks, Vyom   - Original message -From: Julia Boes Sent by: "net-dev" To: net-dev@openjdk.java.netCc:Subject: [EXTERNAL] RFR: 8209178: Proxied HttpsURLConnection doesn't send BODY when retrying POST requestDate: Tue, Se

Enable system proxies by default on Linux?

Using network proxies with Java applications is still, after all these years, painful on Linux. Is there a reason not to change the default value of the system property `java.net.useSystemProxies` [1] to `true`? This would still give priority to the system properties `http.proxyHost`, `ftp.proxyH

Re: Socket timeout semantics

On 24/09/2019 16:32, Milan Mimica wrote: : I looked into it and found this: The difference is how Java_sun_nio_ch_Net_poll is implemented. On unix it uses poll(2), on Windows it uses select(2). Regarding timeouts, poll() has "wait at least"[2] semantics and overruns by design, while select() on

Socket timeout semantics

Hello list While working on the test for JDK-8228580 on core-libs-dev[1] we came across inconsistent behaviour of Socket::setSoTimeout over different platforms: In case there is no data to read, on Windows, client socket.getInputStream().read(...) can return *earlier* than timeout specified, while

Re: RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

On 24/09/2019 16:01, Patrick Concannon wrote: Hi, Would it be possible to have both my fix JDK-8230946, and CSR JDK-8231305, reviewed? This fix and CSR addresses the javadocs for DatagramSocket::receive, DatagramChannel::connect and DatagramChannel::receive and aims at clarifying the Secur

RFR: 8209178: Proxied HttpsURLConnection doesn't send BODY when retrying POST request

Hi, This fix addresses an issue in HttpClient when retrying a POST request over proxied HTTPS. In this case, the request body is stored in a PosterOutputStream poster, which is set to null in sun/net/www/protocol/http/HttpURLConnection::sendCONNECTRequest after the first request. The fix ad

RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

Hi, Would it be possible to have both my fix JDK-8230946, and CSR JDK-8231305, reviewed? This fix and CSR addresses the javadocs for DatagramSocket::receive, DatagramChannel::connect and DatagramChannel::receive and aims at clarifying the Security Manager behaviour on a connected DatagramS

Re: RFR[8217825]: Verify @AfterTest is used correctly in WebSocket tests

Thanks Patrick! I pushed it. best regards, -- daniel On 23/09/2019 18:13, Patrick Concannon wrote: Hi Pavel, Thanks for the feedback. I've incorporated the changes you suggested, and you can find them in the new webrev below. http://cr.openjdk.java.net/~pconcannon/8217825/webrevs/webrev.02