Why is an URL marked as CONFIDENTIAL in web.xml not being rewritten with HTTPS by HttpServletResponse.encodeURL()?

For my java webapp, I would like a log-in form to appear on each (JSP) page if the user is not yet logged. Pages could be secure (HTTPS) or not (HTTP).

The log-in form must POST on a secured (HTTPS) URL to prevent the username/password to be sent in clear text.

If the user is currently on the page http://localhost:8080/app/home, using jstl [c:url value="/login"] to compute the log-in form URL will not change the scheme from HTTP to HTTPS (although /login is marked as CONFIDENTIAL in my web.xml). Instead, it will give an URL like http://localhost:8080/app/login which will send a redirect to https://localhost:8443/app/login when accessed. So why is the container redirecting instead of rewriting the URL to use the correct scheme (+ port) in the first place?

I could hardcode the log-in form secured URL 开发者_如何转开发but that would be less portable.

Or maybe, there are some considerations about web security I'm not aware of...

When you use "/login" as the URL, the browser will interpret the URL as having the same hostname, port and scheme as the URL of the page containing the URL. If you want to use HTTPS, your server-side has to return HTML that uses URL with (at least) the "https:" scheme. This specified in the HTML spec.

However, you don't necessarily have to hard-wire the hostname into the JSP. The JSP could pick up the hostname from configuration property, or figure it out from the current request URL.

But is there a standard way to ask the container (jetty, tomcat...) to convert "/login" into a full secure URL like localhost:8443/app/login ?

AFAIK, no. (BTW, if there was Jetty or Tomcat specific way of doing this, it wouldn't be standard ...)

The container is able to send a redirect to the right secure URL when I try to access the non-secure one, so why not skip the redirection part and make it produce the secure URL through response.encodeURL()?

Good question.

As I understand it, the feature that automatically incoming requests to a secure URL is container specific, and needs to be configured at the container level. Specifically, the container (or something) needs to be told what incoming URLs need this treatment. The JSP engine would need similar information to do the same thing when creating URLs for outgoing messages. AFAIK, there is no such facility in Tomcat's JSP configurations.

You'd need to ask someone on the JSR committee(s) that produced the Java EE specs for an answer as to why there is no standard way to do this.

Even if I can figure the hostname out from the current request URL, I still have to know the HTTPS port (443? 8443?). If this port changes, it must be changed in both server and application config

That is true, but changing a configuration parameter in two places is a minor thing.

And like I said, if you have a beef with the various standards groups for not providing a standard solution for this ... or with the Tomcat / Jetty implementors for not providing a non-standard solution ... you should take this up with THEM.

FWIW, I use a custom "secureURL" tag to solve this problem, but my use-case is significantly more complicated. I'm implementing components that can be dropped into existing sites and that need to work when https is available or is not available, and when secure cookies are used or not used ... for example.