RFR 8133686: REOPEN JDK-8080659 : HttpURLConnection?s getHeaderFields method returns field values in reverse order

[Evan Whelan]

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.whelan at oracle.com>; net-dev at 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