Hi, Tomcat shows error as "This combination of host and port requires TLS." when user is trying to access a URL using http where https is required. In our application all the requests and responses use UTF-8 only. Since this message is hardcoded in org.apache.tomcat.util.net.TLSClientHelloExtractor.java with ISO-8859-1, we could not instruct tomcat to show this message using UTF-8. Can you please fix this and let us know configuration to pass charset that tomcat can use for this message. thanks and regards, Madhav Pulipaka
I'm curious. What is the use case for this (other than wanting everything to be UTF-8 for $reasons)? The response is correctly signalled as ISO-8859-1 encoded and is spec compliant. To put it another way, I'm struggling to identify a scenario where this would not work as intended so why spend time making this configurable?
(In reply to Mark Thomas from comment #1) > I'm curious. What is the use case for this (other than wanting everything to > be UTF-8 for $reasons)? > > The response is correctly signalled as ISO-8859-1 encoded and is spec > compliant. > > To put it another way, I'm struggling to identify a scenario where this > would not work as intended so why spend time making this configurable? I share this opinion, one could of course turn into US-ASCII, but hat won't change anything here.
(In reply to Mark Thomas from comment #1) > The response is correctly signalled as ISO-8859-1 encoded and is spec > compliant. How long before we stuff the response text into a localized properties file and have to chance it to UTF-8 to make it work? Perhaps /we/ should bend rather than the bug reporter?
If you i18n the message that that needs to be driven by the user agent's locale rather than the server locale which would make the whole process significantly more complicated. I don't see that change being made for this feature. I'm not against switching the hard-coded message to UTF-8 - that would be consistent with Tomcat's use of UTF-8 elsewhere and would also be a slightly shorter response. What I am against is making this encoding configurable without an acceptable justification for adding that complexity.
(In reply to Mark Thomas from comment #4) > If you i18n the message that that needs to be driven by the user agent's > locale rather than the server locale which would make the whole process > significantly more complicated. I don't see that change being made for this > feature. > > I'm not against switching the hard-coded message to UTF-8 - that would be > consistent with Tomcat's use of UTF-8 elsewhere and would also be a slightly > shorter response. +1 > What I am against is making this encoding configurable without an acceptable > justification for adding that complexity. +1
Thanks for your response, Converting the message to UTF-8 is sufficient so that all messages to client will be in UTF-8. Please ignore my request on making it configurable. regards, Madhav Pulipaka
Fixed in: - master for 9.0.31 onwards - 8.5.x for 8.5.51 onwards Feature is not present in 7.0.x
Thank you team, Please help with the same fix in tomcat-embed-core also and also let us know when 8.5.51 will be available from maven central. regards, Madhav Pulipaka