Remove UTF-8 charset parameter from Content-Type in SseEmitter

[sada-sigsci]

SseEmitter is adding header "Content-type:text/event-stream;charset=UTF-8".
Golang revproxy is expecting header "Content-Type: text/event-stream" for
immediately flushing the event stream.

HTML standard says [ https://html.spec.whatwg.org/multipage/server-sent-events.html#sse-processing-model ]
ignore the MIME type param and the data is always expected in utf-8.

https://github.com/golang/go/blob/master/src/net/http/httputil/reverseproxy.go#L374

[pivotal-issuemaster]

@sada-sigsci Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-issuemaster]

@sada-sigsci Thank you for signing the Contributor License Agreement!

[rstoyanchev]

The origin of this seems to be #18978 which was added as a workaround for spring-projects/spring-boot#6230.

I don't entirely understand the original issue since the sample project repo is now gone. My assumption is that as a result of spring-projects/spring-boot#5459, use of spring.http.encoding.force-response=true started to set the charset on every response, and if that charset was ISO-8859-1 you'd get that also on SSE where it's wrong.

The workaround to add charset=UTF-8 to SSE responses does not seem to be free of side effects, as this issue shows, and we went through a similar cycle with removing the charset from application/json, see #22788.

I've accepted this for 5.2.5 but I'll allow some time for the Boot team to comment before processing this. /cc @bclozel @wilkinsona

[wilkinsona]

Thanks, @rstoyanchev. My memory of the Boot issue is hazy at best but I think the problem was reported when we were enforcing the encoding on both requests and responses. That was then split out so that it was only done for requests by default. If that's correct, you'd have to explicitly set spring.http.encoding.force-response=true to encounter the problem. As it was Jetty-specific, there may also be a bit more to it. I think we'd have to try and recreate the original problem to learn more.

[rstoyanchev]

Okay, I think we need to process this change to start. If that still causes the original side effect on Jetty with spring.http.encoding.force-response=true, we could call response.setCharacterEncoding(null) in the handling for SSE effectively undoing the forced charset, which causes issues for media types that are not expected to have a charset parameter.

[sada-sigsci]

Thank you so much.