HTTP/308 handling in HttpURLConnection

[Robert Stupp]

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.


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 <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 <https://www.rfc-editor.org/rfc/rfc9110.html#name-308-permanent-redirect>, obsoleted https://www.rfc-editor.org/rfc/rfc7538 <https://www.rfc-editor.org/rfc/rfc7538>, obsoleted https://www.rfc-editor.org/rfc/rfc7238 <https://www.rfc-editor.org/rfc/rfc7238>