Zuul doesn't work correctly with content-type of type multipart/mixed

[MarkBramnik]

Bug Report:

Summary: When sending to Zuul request of type multipart/mixed it doesn't process the request body so that when it forwards a request it comes out with an empty body.

Applicable to (in my checks):

• spring-cloud-netflix-core-1.4.0.RELEASE

My Spring boot application runs with @EnabledZuulProxy Sample request to illustrate the issue:

POST /someArbitraryUrl HTTP/1.1
Content-Type: multipart/mixed; boundary=96498b00-a91c-4858-b5c6-6d46475c6290
Content-Length: 418
Host: localhost:8888
Connection: close
User-Agent: okhttp/3.8.1

--96498b00-a91c-4858-b5c6-6d46475c6290
Content-Disposition: form-data;name="file";filename="SampleText.txt"
Content-Type: text/plain
Content-Length: 24

Hello World
How are you?
--96498b00-a91c-4858-b5c6-6d46475c6290
Content-Disposition: form-data;name="file";filename="AnotherSampleText.txt"
Content-Type: text/plain
Content-Length: 25

I'm fine, thanks
And you?
--96498b00-a91c-4858-b5c6-6d46475c6290--

[ryanjbaxter]

Please learn how to format code on GitHub.

Also please provide a project that reproduces the issue

[jebeaudet]

I believe you might need the fix mentioned in https://github.com/spring-cloud/spring-cloud-netflix/issues/1751

[MarkBramnik]

Thanks, @jebeaudet,

I'm sorry just had no time to provide a working project that demonstrates this issue (we've just used form-data instead and it worked). In my understanding When the query just like I've put in a bug description is submitted to Zuul enabled microservice with content-type multipart/mixed (it's different than form-data), the spring cloud doesn't know how to handle it, if I remember correctly, it has a special filter (FormBodyWrapperFilter) that doesn't know how to handle the content type of such a request, although its a valid http request and we have a REST controller in our business-side microservice (I mean, not the gateway with a Zuul, but different spring boot application) that handles it.

When I've faced this issue, I've just put a redirection rule to locally installed Burp - that just showed me that the request produced by Zuul is empty and doesn't have data mentioned in a form in the original request in an example (Hello World How are you? etc.)

So probably it's a different issue.

[hellojukay]

i have the same problem, my spring cloud version is Edgware.RELEASE

[ryanjbaxter]

@hellojukay can you provide a sample that reproduces the issue?

[valery-lezhebokov]

we have the same isssue. @hellojukay did you manage to make it work with multipart/mixed?

[spencergibb]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.