Describe the bug I have http.headers().httpStrictTransportSecurity disabled. No https even configured. No certificate - nothing. I can browse my resorces via http ok until I try to access any of them via https. In this case HSTS header being send and browser does not want to use http anymore unless its state cleared explicitly. And no resource being served of cause, since https does not configured properly.

To Reproduce * make new spring-boot app with http.headers().httpStrictTransportSecurity disabled. * add static resource. * request it first via http - should be served. * request it via https - get error. * request it via http again - be redirected and get error again.

Expected behavior HSTS to be turned off when it told to. Or even HSTS not to be enabled unless https actually set up and there is a secure server to redirect to.

Comment From: rwinch

No https even configured. No certificate - nothing. I can browse my resorces via http ok until I try to access any of them via https. In this case HSTS header being send and browser does not want to use http anymore unless its state cleared explicitly.

Can you help me understand how this happens? If you don't have https enabled at all, then you should get an error that it could not connect to the port.

Can you show me an example request/response including all the headers?

Can you provide a sample?

Comment From: guai

"you should get an error" I do. it tries to go to 8080 with encripted data it seems. And it fails of cause. "Can you provide a sample" here you go I put a log and some screenshots there. 1) I cleaned the hsts for localhost 2) http 3) https 4) http again

Comment From: rwinch

Invoking httpStrictTransportSecurity().disable() will ensure that the Strict-Transport-Security header is not sent back. Your screenshots do not indicate that it is being sent back (it shows the request headers). What is interesting is the https image shows err_ssl_protocol_error which demonstrates that you are trying to use https protocol on a port that is configured for http. It is my guess that you would not even connect to an HTTP connector when using https (I believe that is what the port is stating). I'd suggest trying from a command prompt and other browsers to see if it appears to behave the same way. If that doesn't help, please provide all the request/response details (including headers) for each of the requests. If you do not see the Strict-Transport-Security header, then Spring Security is behaving properly.

Comment From: guai

"Spring Security is behaving properly" Then why am I getting 307 redirect to Location: https://...? see 4 screenshot Non-Authoritative-Reason: HSTS

Comment From: guai

"you are trying to use https protocol on a port that is configured for http" I'm not. I don't want https in any way, but I still get it. There is an error in the log

2021-02-20 11:55:15.727  INFO 18680 --- [nio-8080-exec-1] o.apache.coyote.http11.Http11Processor   : Error parsing HTTP request header
 Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.

java.lang.IllegalArgumentException: Invalid character found in method name [0x160x030x010x020x000x010x000x010xfc0x030x03F0xe7Y0x810xb1>0x9f0xe7z0x05=0xcc0x070xe1U0xc520x18(0x910x1d0xb00xd9Ux+m0xfb`0x0e0x1aR]. HTTP method names must be tokens

which I think means that https-encrypted request goes to http port.

Comment From: rwinch

Can you try removing Spring Security and seeing if you are still getting the error?

Comment From: guai

Isn't HSTS on by default now? I think I'll get HSTS even earlyer if I try.

Comment From: guai

Yep. After cleaning HSTS cache in the the browser (MS Edge) the first request to http went ok. I got the requested index.html Then I hit F5 to reload it and got 307 status and a redirect to https

Comment From: rwinch

If you still get the problem without Spring Security on your classpath, then how can Spring Security be the problem?

Comment From: guai

Because it have some code in it to turn HSTS off, which it kinda does, but not completely

Comment From: guai

And its not actually the same problem. The issue is about the case when any https request turns HSTS back on, not about HTST pre se

Comment From: rwinch

It disables sending the header. The header is not sent when it is invoked, so this is not a bug.

Comment From: guai

how is this not a bug? redirect withNon-Authoritative-Reason: HSTS I made you an example did you even try it?

Comment From: 2is10

A 307 Internal Redirect with Non-Authoritative-Reason: HSTS is a built-in Chrome behavior. It means Chrome made no server request at all. I don’t know what precisely triggers that behavior. To see how your server actually handles the same request, try a different browser or curl.