Bug 63966

Summary:	Charset of TLS message is hardcoded to ISO-8859-1.
Product:	Tomcat 8	Reporter:	madhavpulipaka
Component:	Catalina	Assignee:	Tomcat Developers Mailing List <dev>
Status:	RESOLVED FIXED
Severity:	enhancement	CC:	michaelo
Priority:	P2
Version:	8.5.32
Target Milestone:	----
Hardware:	All
OS:	All

Description madhavpulipaka 2019-11-27 09:23:51 UTC

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

Comment 1 Mark Thomas 2019-11-27 15:01:41 UTC

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?

Comment 2 Michael Osipov 2019-11-27 15:15:46 UTC

(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.

Comment 3 Christopher Schultz 2019-11-28 02:23:27 UTC

(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?

Comment 4 Mark Thomas 2019-11-28 08:29:33 UTC

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.

Comment 5 Christopher Schultz 2019-12-02 15:58:22 UTC

(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

Comment 6 madhavpulipaka 2019-12-06 12:24:05 UTC

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

Comment 7 Mark Thomas 2020-01-06 21:29:11 UTC

Fixed in:
- master for 9.0.31 onwards
- 8.5.x for 8.5.51 onwards

Feature is not present in 7.0.x

Comment 8 madhavpulipaka 2020-01-07 16:16:30 UTC

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