[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