On 17.01.23 13:09, Olaf Kock wrote:
On 17.01.23 11:45, Deepti Sharma S wrote:
Hello,
I have tried with both Chrome and Mozilla in private window where
information is not cached. HSTS is not working on custom ports.
I'm not confident that HSTS is among those cached values that are not
shared between normal and incognito mode.
Try curl -v
As far as I know, curl does not save any HSTS state anywhere.
Thomas' suggestion makes the most sense: Once your browser knows
positively that it absolutely must connect through https on port 443,
I can easily imagine it never even to attempt to try 8080.
I should have edited ^ this after adding the specs from RFC 6797: Once
the browser knows that it *must* use https for this host, it will not
connect through http, no matter which port. The browser keeps records of
this by domain name, not by name/port.
Also, according to the specs: The browser will - under no
circumstances - connect to your host through http.
The specs say:
|The UA MUST replace the URI scheme with "https" [RFC2818], and if the
URI contains an explicit port component of "80", then the UA MUST
convert the port component to be "443", or>> if the URI contains an
explicit port component that is not equal to "80", the port component
value MUST be preserved; otherwise, if the URI does not contain an
explicit port component, the UA MUST NOT add one. NOTE: These steps
ensure that the HSTS Policy applies to HTTP over any TCP port of an
HSTS Host.|
So, if you connect to 8080 from your browser, your browser would try
to speak https to port 8080 if it has already seen the HSTS header
before.
Olaf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
