Why does request.getRequestURL() return non-https url?

Question

In one of our projects we still have to use JSF 1.2 + Tomcat 6 and the problem is when I'm sending https-request to the server and trying to get requested URL in the managed bean as follows:

ExternalContext context = FacesContext.getCurrentInstance().getExternalContext();
HttpServletRequest request = (HttpServletRequest)context.getRequest();
String url = request.getRequestURL().toString()

The button that sends the request is just a submit-button looked as follows:

<h:form id="contactform">
    <h:commandButton id="submit" action="#{forgotPasswordBean.doSend}"
 </h:form>

I get http-based URL intead of https. In the web-browser's debug panel I made sure that an https-request was actually sent, but URL contained a link to just http request. What's a problem or it's just a bug?

Solution 1

The HttpServletRequest#getRequestUrl() contains the protocol, server name, port number and server path, i.e. it should contain https if the connection is actually secured and is under HTTP.

However, this is not the only way to determine if the connection is secured. The ServelRequest interface defines two more options (ServletRequest#getScheme() and ServletRequest#isSecure()) to detect if the request is secured or not:

String scheme = request.getScheme(); //will return "https" when connection is secured
//or
boolean isSecured = request.isSecure(); //will return true when connection is secured

More info:

• How to check if the request to a Servlet is secured or not?

Solution 2

This behavior can happen if you have a load-balancer in front of the application. Even though requests are done in HTTPS the load-balancer will reissue them as plain http requests which produce this behavior.

One example is when using GAE (Google App Engine). You can use an HTTPS endpoint (https://my-app.appspot.com) but your app will continue to receive all requests in HTTP.

This was pointed out by @user3663882 under comments of approved answer.

Comments

[user3663882]

Actually, the problem was that we have a load-blancer that sends plain-http request.

[Kukeltje]

A good loadbalancer passes at least some additional http header that indicates it was a secure connection