Hi Aleksei,
I believe I'd prefer to move these two lines:
322 String prefer4 =
GetPropertyAction.privilegedGetProperty("java.net.preferIPv4Stack");
323 onlyIPv4Addresses = Boolean.parseBoolean(prefer4);
324
(and the declaration of onlyIPv4Addresses)
to the HostsFileNameServ
Looks good Michael.
Probably deserves testing with tier1-3 to make sure
all subtypes of s.n.w.URLConnection are tested.
best regards,
-- daniel
On 22/05/2020 19:07, Michael McMahon wrote:
Daniel,
Yes, good point. The webrev is updated in place at:
http://cr.openjdk.java.net/~michaelm/824138
Daniel,
Yes, good point. The webrev is updated in place at:
http://cr.openjdk.java.net/~michaelm/8241389/webrev.2/
Thanks,
Michael
On 22/05/2020 16:29, Daniel Fuchs wrote:
Hi Michael,
126 } catch (IOException e) {
127 headerFields = super.getHeaderFields();
12
Thanks Daniel and Patrick. We will push the following for this:
http://cr.openjdk.java.net/~sviswanathan/Vladimir/8245517/webrev.01/
Best Regards,
Sandhya
-Original Message-
From: net-dev On Behalf Of Daniel Fuchs
Sent: Friday, May 22, 2020 8:21 AM
To: Patrick Concannon ; Ivanov, Vladim
Hi,
The "java.net.preferIPv4Stack" and "java.net.preferIPv6Addresses" system
properties do not affect the addresses and their order, returned by the
HostsFileNameService provider that can be created by specifying
"jdk.net.hosts.file" system property.
The following fix analyses the system prope
Hi Michael,
126 } catch (IOException e) {
127 headerFields = super.getHeaderFields();
128 }
I'm not sure that's correct. Could a second attempt to connect()
succeed later? If so it would be more correct to return
super.getHeaderFields() without setting
Hi Vladimir,
The tests came back green :-)
You're good to go for JDK-8245569.
best regards,
-- daniel
On 21/05/2020 20:38, Daniel Fuchs wrote:
Hi Vladimir,
That looks good. Give me time to send that to our test system
and I'll report back.
best regards,
-- daniel
On 21/05/2020 18:07, Iva
On 22/05/2020 10:07, Patrick Concannon wrote:
The test AfterClose.java was added to ProblemList.txt after it was seen
to be failing[1]. You'll need to remove it from the list along with your
proposed fix.
Right. Thanks for chiming in Patrick!
Vladimir, I ran your patch after removing AfterClos
Thanks for the comments Daniel.
Webrev updated at: http://cr.openjdk.java.net/~michaelm/8241389/webrev.2/
- Michael
On 22/05/2020 15:28, Daniel Fuchs wrote:
Hi Michael,
Two comments:
URLConnection.java:
1. I don't think getHeaderFields() should return null,
but an empty map instead.
12
Hi Michael,
Two comments:
URLConnection.java:
1. I don't think getHeaderFields() should return null,
but an empty map instead.
122 return null;
should probably return super.getHeaderFields(); instead.
2. Other methods in this class seem to assume that
`properties` c
Thanks for posting here Moataz,
I am busy with other work at the moment, but just to say that providing some
level of support for multipart has come up a number of times (it is very
useful). The built-in body publishers and subscribers are deliberately minimal,
but it does seem that, at least,
Hi,
Could I get the following fix reviewed please? It is related
to the issue reviewed earlier, but requires a code change
instead of a spec update.
Bug: https://bugs.openjdk.java.net/browse/JDK-8241389
Webrev: http://cr.openjdk.java.net/~michaelm/8241389/webrev.1/index.html
Thanks,
Michael.
Hi Michael
Thanks for the detailed explanation. I'll start work for the possibility for
multiple cname objects.
Regards
Jay
-Michael McMahon wrote: -
To: Jayashree Sk1
From: Michael McMahon
Date: 05/22/2020 06:06PM
Cc: net-dev@openjdk.java.net
Subject: [EXTERNAL] Re: RFR: 824337
Hi Jay,
What I was referring to is something different. DNS reverse lookups
don't use CNAME records. They use PTR records constructed from the IP
address
written in reverse and suffixed with .in-addr.arpa. So, to do a reverse
lookup
of 183.79.131.212, you must look for a PTR record at
212.131.
LGTM.
-Chris.
> On 22 May 2020, at 09:53, Daniel Fuchs wrote:
>
> Hi Michael,
>
> This looks good to me.
>
> best regards,
>
> -- daniel
>
> On 22/05/2020 09:36, Michael McMahon wrote:
>> Hi,
>> Could I get the following small spec clarification reviewed please?
>> Bug: https://bugs.openjdk
Hi Michael
Below are my findings:
1. The fix would have to account for the possibility of multiple canonical
names (obtained from DNS reverse lookup).
Ans:
There is no need for us consider the multiple addresses in getCanonName
because, each of the multiple ip’s DNS reverse lookup with always
Hi Vladimir,
The test AfterClose.java was added to ProblemList.txt after it was seen
to be failing[1]. You'll need to remove it from the list along with your
proposed fix.
[1] https://bugs.openjdk.java.net/browse/JDK-8245518
Kind regards,
Patrick
On 21/05/2020 20:31, Daniel Fuchs wrote:
Hi Michael,
This looks good to me.
best regards,
-- daniel
On 22/05/2020 09:36, Michael McMahon wrote:
Hi,
Could I get the following small spec clarification reviewed please?
Bug: https://bugs.openjdk.java.net/browse/JDK-8241378
CSR: https://bugs.openjdk.java.net/browse/JDK-8245582
Webrev
Hi,
Could I get the following small spec clarification reviewed please?
Bug: https://bugs.openjdk.java.net/browse/JDK-8241378
CSR: https://bugs.openjdk.java.net/browse/JDK-8245582
Webrev: http://cr.openjdk.java.net/~michaelm/8241378/webrev.1/index.html
Thanks,
Michael.
19 matches
Mail list logo
