If your JSP application is being accessed over plain HTTP, you should redirect all public traffic to HTTPS as early as possible. On a hosting platform with Plesk and Java hosting, this is usually handled at the web server level, while the JSP/Tomcat application stays focused on application logic. The exact setup depends on whether your site is served through Apache, a reverse proxy, or a custom Java stack such as My App Server with Apache Tomcat and a private JVM.
For UK-hosted public applications, the main goal is the same: make sure visitors, login forms, session cookies, and any sensitive requests are always sent over an encrypted connection. In most cases, you will want to install a valid SSL certificate, force a redirect from HTTP to HTTPS, and confirm that the application does not generate insecure internal links or redirects.
Why forcing HTTPS matters for a JSP application
JSP applications often handle sessions, login pages, contact forms, account areas, or API calls. If the application is available over HTTP and HTTPS at the same time, users may reach the non-secure version, which can expose cookies or create mixed content issues. For a hosting environment, forcing HTTPS also helps keep the canonical URL consistent and reduces duplicate content problems for search engines.
- Protects credentials and session data in transit
- Helps browsers trust the site and show the secure padlock
- Prevents users from bookmarking or sharing HTTP URLs
- Improves SEO consistency by consolidating traffic on one secure version
- Reduces the risk of mixed content warnings in JSP pages, includes, or templates
Before you start: check the hosting and certificate setup
Before you apply any redirect rules, confirm that HTTPS is already working. For a JSP site on a hosting platform, the certificate is usually installed on the domain in Plesk, and the application is then served through Apache, Tomcat, or both. If you use My App Server, your JSP application may run in its own Tomcat instance or private JVM, but the public HTTPS handling still depends on the web server layer in front of it.
Verify these basics first
- The domain resolves correctly and points to the active hosting account
- An SSL/TLS certificate is installed and valid for the hostname
- HTTPS loads without browser errors
- The application responds correctly when opened with https://
- You know whether Apache, Tomcat, or a proxy is handling public traffic
If HTTPS is not already active, install or renew the certificate first. For UK public-facing sites, a standard trusted certificate is usually the right option. If your hosting plan includes automatic certificate management through Plesk, use that where possible, because it simplifies renewals and reduces downtime risk.
Common ways to force HTTPS on JSP hosting
There are several ways to force HTTPS, depending on how the application is deployed. In managed hosting environments, the cleanest option is usually a server-side redirect in Apache or in Plesk. If your JSP app sits behind Tomcat or uses a custom app server, you may also need application-level awareness so that generated links, redirects, and cookies use HTTPS correctly.
1. Redirect HTTP to HTTPS at the web server level
This is the most reliable approach when Apache is serving the public domain. It catches all incoming HTTP requests before they reach the JSP application and sends them to the secure version.
Typical advantages:
- Works for the whole domain, not just one page
- Does not require changes in JSP code for basic redirecting
- Easy to manage in Plesk or Apache configuration
In many hosting environments, you can add a rule in the site’s Apache configuration or in a per-site override file. If the hosting platform provides a control panel switch for “Force HTTPS” or “Permanent SEO-safe redirect,” use that where available.
2. Use a Plesk redirect or hosting panel option
If your hosting account is managed through Plesk, there may be an option in the domain settings to force HTTPS automatically. This is often the simplest method for standard sites because it avoids manual rule management and is less likely to be broken by app updates.
Look for settings related to:
- Hosting settings
- Permanent SEO-safe redirect from HTTP to HTTPS
- SSL/TLS support
- Preferred domain canonicalization
If your site uses a Java application deployed through My App Server, the hosting platform may still use Apache as the public entry point. In that case, the Plesk-level redirect is usually preferable to application-code redirects, because it is applied before the request reaches Tomcat.
3. Redirect in the JSP application itself
In some cases, especially when a JSP application is behind a proxy or when you need custom logic, you may implement HTTPS enforcement in application code. This is usually a fallback, not the first choice, because server-level redirects are simpler and more efficient.
A JSP-based redirect can be useful if you need to:
- Redirect only certain paths to HTTPS
- Keep specific health-check or internal endpoints on HTTP
- Apply custom logic before redirecting
- Handle proxy headers in a more controlled way
Even then, make sure the redirect logic is careful not to create loops, especially if Tomcat is behind Apache or another proxy that already terminates SSL.
Recommended setup for JSP and Tomcat hosting
For a typical JSP application hosted on a managed platform, the best practice is:
- Install a valid SSL certificate for the domain
- Enable HTTPS for the site in Plesk
- Force an HTTP to HTTPS redirect at the Apache or panel level
- Confirm that Tomcat/My App Server sees the original secure request correctly
- Update the application so all internal links and generated URLs use HTTPS
This approach keeps the redirect outside the app where possible, while still making sure the JSP application knows it is serving secure traffic.
How to force HTTPS in Apache for a JSP site
If Apache is fronting the application, you can usually add a rewrite rule for the site. In managed hosting, this is often done through the domain’s Apache directives or through a configuration file allowed by the hosting platform.
A common pattern is to redirect all requests arriving on port 80 to the same host and URI on HTTPS. Make sure the redirect is permanent so browsers and search engines treat the secure version as canonical.
What the rule should do
- Check whether the request is not already using HTTPS
- Redirect to the same host and path over https://
- Preserve the request URI and query string
- Use a 301 permanent redirect for public sites
If you are using a custom Apache setup through hosting control panel access, place the redirect in the correct virtual host or site-specific override area. Avoid global changes unless you manage multiple domains and know the impact.
Things to avoid
- Redirect loops caused by incorrect proxy or SSL detection
- Mixing HTTP and HTTPS rules in multiple places
- Redirecting too late, after the application has already generated content
- Using temporary redirects for a permanent site migration
How to handle HTTPS with My App Server and Tomcat
With My App Server, you can run your own Apache Tomcat or private JVM inside a shared hosting account, which is useful for Java hosting, JSP hosting, servlet hosting, and small to medium custom applications. In that model, the public web request may still be handled by Apache or the hosting layer before reaching Tomcat. That means HTTPS enforcement is often best applied at the edge, not inside the Java runtime.
When Tomcat is behind Apache
If Apache terminates SSL and forwards requests to Tomcat, the application should trust the proxy-provided headers so it can detect that the original request was secure. If this is not configured properly, your JSP app may think the request is HTTP and generate insecure links or unnecessary redirects.
Check that the application and server configuration can correctly read:
- X-Forwarded-Proto
- X-Forwarded-Host
- X-Forwarded-Port
The exact handling depends on how the hosting platform and your Tomcat instance are configured. In a managed hosting environment, the goal is to ensure that the public request scheme is communicated properly to the application.
When Tomcat handles SSL directly
If Tomcat is listening directly on an SSL connector, then HTTPS enforcement may be configured within the Tomcat connector or application logic. This is less common in managed shared hosting, but it can be used in custom app server setups.
Even in that case, a site-wide redirect strategy is still recommended so that users never stay on the HTTP version. If Apache is also present, do not configure both layers to redirect the same traffic unless you have checked the logic carefully.
JSP application changes you may need after forcing HTTPS
Redirecting traffic is only one part of the job. A JSP application may also need a few internal adjustments so the secure version works cleanly.
Update absolute links
If your pages or templates contain hard-coded http:// links, update them to relative URLs or https:// URLs. This is especially important for:
- Navigation menus
- Canonical tags
- Redirect targets
- Static assets such as CSS, JavaScript, and images
- Third-party API endpoints used by the application
Set secure cookies
For login sessions and form handling, make sure cookies are marked appropriately for secure delivery. A cookie used only over HTTPS should usually include the Secure flag, and in many cases HttpOnly is also recommended. If the application supports modern browser behavior, consider SameSite settings as well.
Avoid mixed content
Mixed content occurs when an HTTPS page loads HTTP resources. This can break the padlock icon or cause browsers to block scripts and styles. Common sources include:
- Images embedded with http:// URLs
- JavaScript includes from insecure paths
- Forms posting to HTTP endpoints
- External fonts or analytics scripts loaded insecurely
Run a full check of the JSP templates after the redirect is enabled, especially on login pages and shared layout files.
How to test that HTTPS is forced correctly
After you configure the redirect, test it carefully from an incognito window or a fresh browser session. You should check both the root domain and a few deep links inside the application.
Test checklist
- Open the site with http:// and confirm it redirects to https://
- Check whether the redirect preserves the exact path and query string
- Verify that the secure URL returns the expected page without errors
- Inspect browser warnings for mixed content
- Test login, logout, session timeouts, and form submissions
- Confirm that the application does not bounce between HTTP and HTTPS
If you use a staging environment in the hosting control panel, test the configuration there first. This is especially useful when the JSP application has custom filters, session logic, or front-end assets that may not respect the new scheme immediately.
Common problems and how to fix them
Redirect loop between HTTP and HTTPS
This usually happens when the application or proxy cannot correctly detect the original protocol. Check whether Apache is already terminating SSL and whether Tomcat is seeing the request as HTTPS through forwarded headers. If both Apache and the application try to redirect independently, remove one of the redirect layers.
HTTPS works, but links still point to HTTP
This is a sign that the application is generating absolute URLs using an old base URL or cached configuration. Review JSP templates, base tags, environment settings, and any code that builds links from request data.
The browser shows mixed content warnings
Search your JSP pages and static resources for insecure references. Replace hard-coded HTTP asset URLs with HTTPS or relative paths. Also check included fragments, tag files, and external libraries referenced from the application.
Sessions break after switching to HTTPS
If session cookies were previously set without Secure, or if the app expects HTTP and HTTPS as separate flows, you may see login problems. Review cookie settings and make sure the application understands the secure scheme consistently.
Redirect works on the homepage but not in subdirectories
This usually means the rule was added in the wrong place. Site-wide HTTPS enforcement should be applied at the domain or virtual host level, not just inside a single folder or JSP page.
Best practices for UK public-facing JSP sites
For a public application aimed at users in the UK, the most practical approach is to keep the secure version as the only version users see. That means one canonical hostname, one protocol, and a single redirect path from HTTP to HTTPS. This is especially important for applications that handle logins, quote forms, customer dashboards, or any data submission.
- Use a permanent 301 redirect from HTTP to HTTPS
- Keep the secure hostname consistent across the whole site
- Use valid certificates and renew them before expiry
- Check secure cookie flags for session handling
- Review JSP-generated URLs after every deployment
- Test after changes to Apache, Plesk, or Tomcat configuration
If you manage the application through a hosting control panel, it is usually better to centralize HTTPS enforcement there rather than scattering redirects through JSP pages. That keeps the configuration easier to support and less likely to break during future updates.
FAQ
Should I force HTTPS in JSP code or on the server?
Use the server or control panel first whenever possible. A web server redirect is more reliable and easier to manage. Add application-level handling only if your setup requires it.
Is a 301 redirect the right choice for HTTPS enforcement?
Yes, for a public site that should always use HTTPS. A 301 permanent redirect tells browsers and search engines that the HTTPS version is the preferred one.
Does My App Server change how HTTPS works?
It changes where your JSP application runs, but the public HTTPS redirect still usually belongs at the Apache or hosting layer. My App Server is useful because it gives you control over the Java version, Tomcat instance, and JVM setup, while the secure delivery can still be handled cleanly in the hosting platform.
What if my JSP app is behind a proxy?
Then the application may need to trust forwarded headers to know whether the original request used HTTPS. If this is not configured properly, redirects and URL generation may behave incorrectly.
Can I force HTTPS from a JSP filter?
Yes, but only as a fallback or for special cases. For most hosting setups, a server-side redirect is cleaner and easier to maintain.
Why do I still see HTTP links after enabling HTTPS?
Because the redirect does not automatically rewrite all internal content. You still need to update JSP templates, configuration values, asset URLs, and any code that builds absolute links.
Conclusion
Forcing HTTPS on a JSP application is usually straightforward once the certificate is installed and the public traffic path is clear. In a managed hosting environment, the best solution is typically a permanent redirect at the Apache or Plesk level, combined with a quick review of the JSP application for hard-coded HTTP links, cookie settings, and proxy awareness.
If your application uses My App Server, Apache Tomcat, or a private JVM, the same principle applies: keep HTTPS enforcement at the edge where possible, and make sure the Java application is aware that it is running behind a secure front end. That gives you a cleaner setup, fewer redirect problems, and a safer public-facing application for your users.