Hi, Thanks for the feedback Daniel, I've added the test verifying the issue.
The test checks both getHeaderFields and getRequestProperties. Please find another revision of this fix at: http://cr.openjdk.java.net/~kravikumar/8133686/webrev.03/ A CSR for this issue has also been written and is found at: https://bugs.openjdk.java.net/browse/JDK-8252456 Please let me know if you have any more suggestions or feedback. Kind regards, Evan -----Original Message----- From: Daniel Fuchs Sent: Thursday 27 August 2020 20:01 To: Evan Whelan <evan.whe...@oracle.com>; net-dev@openjdk.java.net Subject: Re: RFR 8133686: REOPEN JDK-8080659 : HttpURLConnection?s getHeaderFields method returns field values in reverse order Hi Evan, Actually - I believe you are still missing a test that verifies the actual issue - that is: If a multi valued field is sent over the wire as a repeated list of headers - that is - if it is transmitted as: foo: foo1 foo: foo2 foo: foo3 then you need to verify that HttpURLConnection.getHeaderFields().get("foo") will now return [foo1, foo2, foo3] and not [foo3, foo2, foo1]. Also I notice that your change also fixes URLConnection::getRequestProperties(), directly implemented in URLConnection, which is both good and bad. Good because the previous behavior was IMO a bug. Bad because it slightly increases the chances of regression (from minimal to low). So I now believe that writing a CSR is indeed required, to raise the awareness on this behavior change. best regards, -- daniel On 20/08/2020 17:06, Evan Whelan wrote: > Hi all, > > A revised webrev for this change can be found at > http://cr.openjdk.java.net/~coffeys/evwhelan/8133686/webrev/ > > This revision fixes a test that failed as a result of the source change. > > If anyone has any further thoughts on whether this change needs a CSR, > I would love to hear them. > > Thanks in advance, > > Evan
