RFR: 8133686: HttpURLConnection.getHeaderFields and URLConnection.getRequestProperties methods return field values in reverse order [v2]

[Daniel Fuchs]

On Mon, 8 Feb 2021 10:10:26 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Evan Whelan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   URLConnection doc fixes
>
> src/java.base/share/classes/java/net/URLConnection.java line 1147:
> 
>> 1145:      * to the map is not supported by the protocol being
>> 1146:      * used in a given subclass.
>> 1147:      *
> 
> I'm not sure about this. What is the use-case driving this clarification? Is it just for the corner case where the default implementation of getHeaderFields is not overridden ?

Many protocol handlers don't support adding request headers (ftp://, file://, mailto:// jrt://) - they all inherit form s.n.www.URLConnection which has this implementation:

    public void addRequestProperty(String key, String value) {
        if (connected)
            throw new IllegalStateException("Already connected");
        if (key == null)
            throw new NullPointerException ("key is null");
    }

> src/java.base/share/classes/java/net/URLConnection.java line 1200:
> 
>> 1198:      * added. This method must preserve the insertion order
>> 1199:      * of such values.
>> 1200:      *
> 
> But we have made addRequestProperty effectively a no-op ( as above ) !

We are allowing it to be a no-op. But if it's not a no-op then it must return values in the order they were added. The other option is to make the order non normative and protocol dependent (and possibly move the normative text to the HttpURLConnection/HttpsURLConnection/JarURLConnection.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2294