Rob Worsnop

I worked around this by providing my own MultipartResolver bean. ```java @Component public class PassthroughMultiPartResolver implements MultipartResolver { @Override public boolean isMultipart(HttpServletRequest request) { // Always pass through multipart requests...

This is because of the way Tomcat's `OutputBuffer` works. That's what is being written to when applications write to a response's `OutputStream`. As its name suggests, it will buffer data...

~~IMO SCG shouldn't need to buffer data it gets back from an origin server in any situation. The origin server itself should have already done that. Perhaps @spencergibb will disagree.~~...

Just to be clear: I am not on the Spring team! I'm just offering my opinions. I would focus on SSE to start with, since it always makes sense to...

@jensmatw Your PR isn't working because you're looking at the server request headers. You need to look at the headers in `clientResponse` available in `doExchange`.

This is the least intrusive workaround I could think of. It does require that clients set the `Accept` header to `text/event-stream`. ```java public class SseFilter extends OncePerRequestFilter { @Override protected...

See https://github.com/spring-cloud/spring-cloud-gateway/pull/3437

I'm not sure this is going to work. Consider the url "http\://example.com/foo–bar foo" (that's an en dash, not a dash): ``` String url = "http://example.com/foo%E2%80%93bar%20foo"; URI uri = URI.create(url); String...

Duplicate of https://github.com/spring-cloud/spring-cloud-gateway/issues/3220

`containsEncodedQuery` can also cause double-encoding. If the (decoded!) query param contains a non-standard char, it will assume everything is not encoded and encode the whole thing again.