Re: HTTP/308 handling in HttpURLConnection

[Robert Stupp]

Yup, I have one. Created https://bugs.openjdk.org/browse/JDK-8288295 


> Am 10.06.2022 um 14:13 schrieb Daniel Fuchs :
> 
> Hi Robert,
> 
> On 10/06/2022 11:54, Robert Stupp wrote:
>> Does anyone recall why HTTP/308 was not implemented that time? I suspect 
>> that HTTP/308 was just not a thing 14/15 years ago, but no clue whether it’s 
>> just not been implemented all the time or whether there was a reason to not 
>> handle it at all in HttpURLConnection. I could not find anything useful in 
>> the OpenJDK commit log nor in the OpenJDK JIRA (there was a ticket about the 
>> Webstart client).
> 
> The history you can observe probably dates back to the time when
> Java was open sourced, but the networking code is probably older
> than that.
> 
> I would guess that 308 was never implemented.
> Do you have an account for https://bugs.openjdk.org/ ?
> If you do please log an RFE (component core-libs, subcomponent
> java.net) and we will evaluate it. Otherwise you can log
> it through https://bugreport.java.com/
> 
> I see that 308 is not very different from 301 except that it
> explicitly prevents turning a POST into a GET on redirection - so
> there may be several places to tweak in the HttpURLConnection code
> if we decided to implement this.
> 
> best regards,
> 
> -- daniel

Re: HTTP/308 handling in HttpURLConnection

[Daniel Fuchs]

Hi Robert,

On 10/06/2022 11:54, Robert Stupp wrote:

Does anyone recall why HTTP/308 was not implemented that time? I suspect that 
HTTP/308 was just not a thing 14/15 years ago, but no clue whether it’s just 
not been implemented all the time or whether there was a reason to not handle 
it at all in HttpURLConnection. I could not find anything useful in the OpenJDK 
commit log nor in the OpenJDK JIRA (there was a ticket about the Webstart 
client).


The history you can observe probably dates back to the time when
Java was open sourced, but the networking code is probably older
than that.

I would guess that 308 was never implemented.
Do you have an account for https://bugs.openjdk.org/ ?
If you do please log an RFE (component core-libs, subcomponent
java.net) and we will evaluate it. Otherwise you can log
it through https://bugreport.java.com/

I see that 308 is not very different from 301 except that it
explicitly prevents turning a POST into a GET on redirection - so
there may be several places to tweak in the HttpURLConnection code
if we decided to implement this.

best regards,

-- daniel

HTTP/308 handling in HttpURLConnection

[Robert Stupp]

[moved from jdk-dev, additional information at the end]

I just stumbled upon a behavior in 
HttpURLConnection.openConnectionCheckRedirects() regarding the HTTP redirect 
handling.

The concrete situation was a http-to-https „upgrade“, when a load balancer 
responds with a HTTP 308 for requests against the insecure endpoint.

The code that handles redirects in the JDK hasn’t been touched since one of the 
„Initial load“ commits about 14/15 years ago. It recognizes the HTTP status 
codes 300, 301, 302, 303, 305 and 307 - but not 308.

I wonder what you guys think, whether 
HttpURLConnection.openConnectionCheckRedirects() should be adopted to handle 
HTTP/308 like all other redirect responses.

The earliest RFC that I could find is RFC-7238, from June 2014, so about 6 
years after the „Initial load“ commit. The current RFC 9110 defines HTTP 308.

Does anyone recall why HTTP/308 was not implemented that time? I suspect that 
HTTP/308 was just not a thing 14/15 years ago, but no clue whether it’s just 
not been implemented all the time or whether there was a reason to not handle 
it at all in HttpURLConnection. I could not find anything useful in the OpenJDK 
commit log nor in the OpenJDK JIRA (there was a ticket about the Webstart 
client).

REST clients are usually configured with a base URL but also send credentials 
(tokens for example). My gut feeling is that „transparently" handling HTTP/308 
on the client would give users and service operators a „false impression of 
security“ - mean: everybody thinks, their data and credentials are transmitted 
w/ proper encryption in place, which is not really wrong, but clients 
additionally expose their credentials and data in clear text.

Browsers rely on HTTP/308 for a while now. People type http://… get a HTTP/308 
to https://… and everything’s fine. There’s likely no real security risk for 
browsers, because HTTP/308 responses are cached and hence credentials are 
probably not „leaked“ over plain text connections.

Of course, the correct way to „handle“ it for HttpURLConnection, would be to 
just configure the „right“ https base URL. And also turn off redirects 
completely on HttpURLConnection.

[end of message sent to jdk-dev]


On top of that, protocol changes (e.g. http -> https) are rejected by 
HttpURLConnection (i.e. cannot redirect from a http URL to a https URL). But 
changes to the host are allowed.


The new HTTP client implementation works as expected for all known legit HTTP 
redirect responses, conforming to RFC 9110 AFAICT.



Robert




References:

HttpURLConnection „blame": 
https://github.com/openjdk/jdk/blame/e01cd7c3ed923cd19509fc972ba6e4aa2991289f/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L982-L983

Current RFC 9110: 
https://www.rfc-editor.org/rfc/rfc9110.html#name-308-permanent-redirect, 
obsoleted https://www.rfc-editor.org/rfc/rfc7538, obsoleted 
https://www.rfc-editor.org/rfc/rfc7238