Character encoding of ServletOutputStream print methods

[glassfishrobot]

The async API is only available on the output stream. Thus we have had a framework that used to do:

response.setContentType("application/json;charset=UTF-8");
...
response.getWriter().print("Ӝ");

convert to asynchronous style and now it does:

response.setContentType("application/json;charset=UTF-8");
...
response.getOutputStream().print("Ӝ");

This works fine on some containers (eg Jetty), but apparently many containers do not respect the encoding set by the setContentType. They either convert the character as ISO8859-1 or if the first character is UTF-8, they throw a CharacterEncoding exception.

We have also seen at least one container handle the following writes out of order:

response.getOutputStream().print("one");
response.getOutputStream().write("two".getBytes(UTF_8);
response.getOutputStream().print("three");

As the async API will now make more character oriented frameworks use the output stream, I believe that we need to clarify the semantics of the ServletOutputStream print method so that it:

• is definitely mix and match with write - so we must say that print cannot buffer any data.
• respects the character encoding set on the response

[glassfishrobot]

@glassfishrobot Commented
Reported by gregwilkins

[glassfishrobot]

@glassfishrobot Commented
markt_asf said:
I assume you mean ServletOutputStream, not HttpOutputStream.

No issue with saying print cannot buffer data.

More than happy to see the spec be more explicit about char -> byte conversions. Respecting the character encoding set on the response works for synchronous and asynchronous cases but what about HTTP upgrade where there is no response? In this case the user just has the ServletOutputStream. I'm tempted to say add a setCharacterEncoding(String) method to ServletOutputStream but that then creates precedence issues with whatever is set on the Response for the synchronous and asynchronous cases. The precedence issue is solveable - it just adds complexity I'd rather avoid.

[glassfishrobot]

@glassfishrobot Commented
gregwilkins said:
Ooops yes ServletOutputStream

For HTTP upgrade there is still a response as the upgrade has to be responded to before the upgrade takes place. So setting the character encoding on the response before getting the outputstream should work, if a little clumsy.

cheers

[glassfishrobot]

@glassfishrobot Commented
markt_asf said:
I've updated the issue title and description to refer to ServletOutputStream

With respect to HTTP upgrade and setting the character encoding on the response before the upgrade, that only works if the encoding is known at that point. I don't know of a use case where the encoding is not known until after the upgrade but it doesn't seem unreasonable that there might be one.

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA SERVLET_SPEC-112

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/servlet-spec/issues/112
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot

[stuartwdouglas]

With respect to HTTP upgrade I don't think there is a charset that can reasonably be applied, imho print should be limited to US-ASCII for the upgrade use case. For other cases it should use the same charset that would be used by the writer.