Tomcat redirectPort: HTTPS-begränsningar och connectors

Publicerad: 2 januari 2021

Uppdaterad: 2 augusti 2026

Tekniska artiklar > Tomcat redirectPort: HTTPS-begränsningar och connectors

Status 2026 och säker användning

Slutsats: redirectPort anger målporten när en begäran kommer till en icke-TLS-connector och webbapplikationens säkerhetsregel kräver konfidentiell transport. Inställningen skapar inte en TLS-connector och tvingar inte ensam fram HTTPS för alla begäranden.

Det här går artikeln igenom

Hur <transport-guarantee>CONFIDENTIAL</transport-guarantee> utlöser containerhanterad omdirigering.
Varför målporten måste motsvara en fungerande HTTPS-connector eller en korrekt utformad proxytopologi.
Hur TLS direkt i Tomcat skiljer sig från TLS-terminering i Apache HTTP Server eller en annan proxy.

Målgrupp: Administratörer och Java-webbutvecklare som granskar Tomcats connectors och webbapplikationens transportkrav.

Läge 2026: Tomcat 9-exemplet är fortfarande användbart för begreppet, men attribut och proxyhantering måste stämma med den Tomcat-gren som används. Konfigurera betrodda proxyhuvuden uttryckligen för att undvika fel schema, fel port och omdirigeringsslingor.

Säkerhetsinformation: Konfigurationsexemplen har inte testats på nytt i en aktuell produktionsmiljö. Verifiera connectors, certifikat, proxyhuvuden och återställning i en separat testmiljö.

Viktiga officiella källor

Översikt

Tomcats server.xml innehåller ofta attributet redirectPort på en HTTP-connector. Attributet används tillsammans med webbapplikationens transportkrav och en separat HTTPS-lösning.

Exemplet nedan anger port 8443 som mål.

server.xml

    <Connector port="8080" protocol="HTTP/1.1"

               connectionTimeout="20000"

               redirectPort="8443" />

Innehållsförteckning

Vad är redirectPort?
- 1-1. Grund för beteendet
Sammanfattning

1. Vad är redirectPort?

redirectPort anger vart Tomcat ska omdirigera en icke-krypterad begäran när den matchande resursen kräver konfidentiell transport.

Anta att server.xml innehåller följande connector.

server.xml

    <Connector port="8080" protocol="HTTP/1.1"

               connectionTimeout="20000"

               redirectPort="8443" />

En begäran till "http://hoge:8080/hoge.html" kan då omdirigeras till "https://hoge:8443/hoge.html", men endast när applikationens säkerhetsregel kräver det.

Kravet anges i web.xml genom att <transport-guarantee> får värdet CONFIDENTIAL, exempelvis så här.

web.xml

～förkortning～

    <security-constraint>

      <web-resource-collection>

        <web-resource-name>twx-portal</web-resource-name>

        <url-pattern>/*</url-pattern>

      </web-resource-collection>

      <user-data-constraint>

        <transport-guarantee>CONFIDENTIAL</transport-guarantee>

      </user-data-constraint>

    </security-constraint>

</web-app>

URL-mönstret "/*" omfattar alla resurser i webbapplikationen. Utan ett krav på CONFIDENTIAL används redirectPort inte för den här mekanismen. Attributet skapar inte heller en lyssnande TLS-connector på port 8443; målporten måste konfigureras separat eller hanteras korrekt av en omvänd proxy.

1-1. Grund för beteendet

Tomcats dokumentation beskriver sambandet mellan TLS-porten, redirectPort och en säkerhetsregel i webbapplikationen.

http://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html

Om TLS-porten ändras måste redirectPort på den icke-krypterade connectorn uppdateras så att Tomcat kan omdirigera begäranden vars säkerhetsregel kräver TLS.

Det avgörande är alltså säkerhetsregeln i web.xml. När regeln kräver CONFIDENTIAL transport använder Tomcat redirectPort för den containerhanterade omdirigeringen.

2. Sammanfattning

redirectPort används när en begäran till en icke-TLS-connector matchar en säkerhetsregel som kräver CONFIDENTIAL transport.

Konfigurera den verkliga TLS-connectorn eller proxytopologin separat och verifiera målport, schema, vidarebefordrade huvuden och omdirigeringar utan slingor.