Java HTTP Tomcat – How to Redirect HTTPS to HTTP in Tomcat?

httphttpsjavatomcat

Made system update to temporarily disable HTTPS in our Tomcat server.

Previous users are still using Https:// URL to access system and receive error
message because it's disabled.

Would like to redirect users from HTTPS to basic HTTP version of website.

Have tried multiple different Connectors in server.xml file, but sadly no success.

Could a tomcat wizard please share this precious knowledge?

Best Answer

Why can't you disable HTTPS and redirect requests to HTTP?

When a browser makes an HTTPS request the steps go roughly as follows...

Look up the host name (FQDN) in DNS if needed to get an ip address.
Get a TCP connection to the host's ip address on port 443 ( or other you define ).
Try to complete a TLS (or SSL) handshake and start encrypted communication.
And then (finally) the HTTP request is sent over the TLS,TCP connection.

If you disable the connector that was serving HTTPS the process fails at step 2. The browser can't get a TCP connection to port 443.

At that point it can't even send the first HTTP request or receive a redirect response.

When the process fails at step 2 you typically see a long delay followed by the browser's broken looking "site not reachable" page. A Java client typically sees a SocketException.

Can you redirect HTTPS requests to HTTP urls if you do not disable HTTPS?

Yes. This is easy. For example: You can configure a filter that responds with a redirect status code to all requests for the url path range you desire.

For any request to reach this code and get the response you have to enable a connector serving TLS/SSL so the request can be received.
Using the filter approach takes an entry in the web.xml to configure the filter, and a single source file to implement the filter, which would just send back a redirect response when the request scheme is https.

The only "configuration only" redirect feature I'm aware of (Tomcat Connector redirectPort= attribute) is specifically for http to https redirection.

If you do redirect from a url with HTTPS scheme to an HTTP url, I would expect to get some messages or indications from browsers. I have not tested that scenario.

Should you redirect requests on HTTPS urls to HTTP?

In most circumstances this is not a good idea.

Your site will be noted as "not secure" in browsers.
Using HTTP may reduce your search ranking a bit in Google. Does SEO matter?
Even the most public site gives users some protection by using TLS/SSL.

The main use scenarios where I have ever decided to force non-encrypted HTTP are...

in a development environment, for troubleshooting with packet capture.
in 'behind the firewall' communication between my own services for troubleshooting with packet capture.
in communication between services on an already encrypted IPsec VPN

Related Solutions

Why HTTP Doesn’t Have POST Redirect – Web Development Insights

In HTTP 1.1, there actually is a status code (307) which indicates that the request should be repeated using the same method and post data.

As others have said, there is a potential for misuse here which may be why many frameworks stick to 301 and 302 in their abstractions. However, with proper understanding and responsible usage, you should be able to accomplish what you're looking for.

Note that according to the W3.org spec, when the METHOD is not HEAD or GET, user agents should prompt the user before re-executing the request at the new location. You should also provide a note and a fallback mechanism for the user in case old user agents aren't sure what to do with a 307.

Using this form:

<form action="Test307.aspx" method="post">
    <input type="hidden" name="test" value="the test" />
    <input type="submit" value="test" />    
</form>

And having Test307.aspx simply return 307 with the Location:http://google.com, Chrome 13 and Fiddler confirm that "test=the test" is indeed posted to Google. Of course the further response is a 405 since Google doesn't allow the POST, but it shows the mechanics.

For more information see List of HTTP status codes and the W3.org spec.

307 Temporary Redirect (since HTTP/1.1) In this occasion, the request should be repeated with another URI, but future requests can still use the original URI.2 In contrast to 303, the request method should not be changed when reissuing the original request. For instance, a POST request must be repeated using another POST request.

Java – Refactoring Tomcat webapp deployments

In my experience building applications using Maven for Tomcat 6 and Tomcat 7, I never needed to deploy jars explicitly to Tomcat's common lib directory.

Take a look at this post: https://stackoverflow.com/questions/267953/managing-libraries-in-tomcat

Answers there indicate that conflicts may arise between classes in the shared common lib folder, and those in each web application, as each web application may have dependencies of differing versions.

Also, according to the Tomcat page you linked to for Common class loader libraries: "Normally, application classes should NOT be placed here".

For example, if you had log4j-1.2.15.jar in the commons/lib directory, and log4j-1.2.17.jar in your application lib dir, Tomcat may try to load 1.2.15, while your application was written to use 1.2.17, which can lead to ClassNotFoundExceptions, and potentially other exceptions.

I'd recommend only placing libraries that Tomcat needs for itself into the common lib directory, and let each application context load its own dependencies.

If you use Maven (and configure the project correctly), you should not need to manually move any jars around. Gradle may have similar functionality.

Best Answer

Related Solutions

Why HTTP Doesn’t Have POST Redirect – Web Development Insights

Java – Refactoring Tomcat webapp deployments

Related Topic