Regression: sun.net.http.allowRestrictedHeaders is not always respected for restricted headers

[oracle-soa-odcs]

Bug Description

In recent version 2.48, the behavior for handling restricted HTTP headers with the HttpUrlConnector is broken compared to prior Jersey release 2.47.

I am using Oracle OCI SDK 2.x

In Jersey 2.39.1, we saw

Attempt to send restricted header(s) while the 
[sun.net.http.allowRestrictedHeaders] system 
property not set. Header(s) will possibly be ignored

This is because OCI SDK sets Host header for whatever reasons

We thus added sun.net.http.allowRestrictedHeaders system property and life was good

With 2.48, this behavior reverted and we saw this message again even though the system property is set

A code review of v2.48 of HttpUrlConnector shows this exact logic was refactored into a configuration class. Debugger breakpoints show that the HttpUrlConnectorConfiguration.ReadWrite#fromClient method which reads this system property is called in some code paths but not in others leading to the broken behavior

Downgrading to 2.47 restores the expected and presumably correct behavior which further suggests this is a regression

---

What follows is copilot garbage which may or may not be accurate:

Regression Detail

• Previously, the system property sun.net.http.allowRestrictedHeaders was checked directly in HttpUrlConnector. This ensured that setting the property at runtime (before client or target creation) consistently enabled or disabled sending restricted headers like Origin, Host, etc.
• Now, the check is performed only in HttpUrlConnectorConfiguration.ReadWrite#fromClient(Configuration configuration). However, this method is not guaranteed to be called when constructing per-request configuration, so if the property is set or changed after the client is built, new requests may ignore the property—which is incorrect compared to the former behavior.
• The per-request configuration built via fromRequest() does not re-copy or re-check the cached property from the client configuration, leading to requests sometimes ignoring a property set by the user.

Steps to Reproduce

1. Set sun.net.http.allowRestrictedHeaders after the Jersey client is initialized (but before a request is made).
2. Attempt to send restricted headers such as Origin or Host using the default HttpUrlConnector.
3. The headers are not sent, despite the property being set.

Expected Behavior

• When sun.net.http.allowRestrictedHeaders is set to true before a request (but possibly after the client is created), any requests using the default connector should forward restricted headers.
• This was how previous releases of Jersey worked.

Actual Behavior

• Requests may skip sending restricted headers, ignoring the system property even if it is set.

Analysis

• The value of sun.net.http.allowRestrictedHeaders is only cached in the client configuration and not propagated into the per-request configuration in all cases. The old behavior checked the property at request time or always propagated its value.
• This is a regression breaking applications that rely on setting this property to use CORS or custom hosts.

References

• Current HttpUrlConnector.java (line 536)
• Current HttpUrlConnectorConfiguration.java

Proposed Fix

• Ensure that the isRestrictedHeaderPropertySet value is propagated from the client config into each per-request configuration (e.g., update fromRequest() to copy this field).
• Alternatively, check the system property in the per-request configuration or even at actual request execution time, as in the old code.