starred/WireMock.Net-wiremock
1
0
Fork 0
mirror of https://github.com/wiremock/WireMock.Net.git synced 2026-01-11 14:20:29 +01:00
Code Issues 32 Packages Projects Releases 10 Wiki Activity

Content-Type multipart/form-data is not seen as byte[] anymore #162

New Issue
Closed
opened 2025-12-29 14:23:58 +01:00 by adam · 18 comments
adam commented 2025-12-29 14:23:58 +01:00
Owner
Copy Link

Originally created by @bgiot on GitHub (Jan 10, 2019).

Since version 1.0.4.18, if the request body is of content-type "multipart/form-data", it is seen as string body instead of byte body. Bug seems to be in the BodyParser class where the content-type is not check anymore before trying reading the content as string. Before version 1.0.4.18, a check was done to see if the content is of "text" type before trying to convert body to string. Our MultipartMatcher implementation cannot work anymore because of this.

Originally created by @bgiot on GitHub (Jan 10, 2019). Since version 1.0.4.18, if the request body is of content-type "multipart/form-data", it is seen as string body instead of byte body. Bug seems to be in the BodyParser class where the content-type is not check anymore before trying reading the content as string. Before version 1.0.4.18, a check was done to see if the content is of "text" type before trying to convert body to string. Our MultipartMatcher implementation cannot work anymore because of this.
adam closed this issue 2025-12-29 14:23:58 +01:00
adam commented 2025-12-29 14:23:59 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Jan 10, 2019):

Which version are you using now ? 1.0.6 ?

@StefH commented on GitHub (Jan 10, 2019): Which version are you using now ? 1.0.6 ?
adam commented 2025-12-29 14:23:59 +01:00
Author
Owner
Copy Link

@bgiot commented on GitHub (Jan 10, 2019):

It only works with version 1.0.4.17. I tested all the other versions from 1.0.4.18 upto 1.0.6 and I have the issue

@bgiot commented on GitHub (Jan 10, 2019): It only works with version 1.0.4.17. I tested all the other versions from 1.0.4.18 upto 1.0.6 and I have the issue
adam commented 2025-12-29 14:24:00 +01:00
Author
Owner
Copy Link

@bgiot commented on GitHub (Jan 10, 2019):

In version 1.0.4.17, you can see in the BodyParser class that a test is done on the ContentType header before trying to read the body as string (from line 50):

           if (contentTypeHeaderValue != null && TextContentTypes.Any(text => contentTypeHeaderValue.StartsWith(text, StringComparison.OrdinalIgnoreCase)))
            {
                try
                {
                    var stringData = await ReadStringAsync(stream);
                    data.BodyAsString = stringData.Item1;
                    data.Encoding = stringData.Item2;
                }
                catch
                {
                    // Reading as string failed, just get the ByteArray.
                    data.BodyAsBytes = await ReadBytesAsync(stream);
                }
            }
@bgiot commented on GitHub (Jan 10, 2019): In version 1.0.4.17, you can see in the BodyParser class that a test is done on the ContentType header before trying to read the body as string (from line 50): ``` if (contentTypeHeaderValue != null && TextContentTypes.Any(text => contentTypeHeaderValue.StartsWith(text, StringComparison.OrdinalIgnoreCase))) { try { var stringData = await ReadStringAsync(stream); data.BodyAsString = stringData.Item1; data.Encoding = stringData.Item2; } catch { // Reading as string failed, just get the ByteArray. data.BodyAsBytes = await ReadBytesAsync(stream); } } ```
adam commented 2025-12-29 14:24:00 +01:00
Author
Owner
Copy Link

@bgiot commented on GitHub (Jan 10, 2019):

from version 1.0.4.18, the code doesn't check the content type anymore before trying reading body as string:


           var data = new BodyData
            {
                BodyAsBytes = await ReadBytesAsync(stream),
                DetectedBodyType = BodyType.Bytes,
                DetectedBodyTypeFromContentType = DetectBodyTypeFromContentType(contentType)
            };

            // Try to get the body as String
            try
            {
                data.BodyAsString = DefaultEncoding.GetString(data.BodyAsBytes);
                data.Encoding = DefaultEncoding;
                data.DetectedBodyType = BodyType.String;
@bgiot commented on GitHub (Jan 10, 2019): from version 1.0.4.18, the code doesn't check the content type anymore before trying reading body as string: ``` var data = new BodyData { BodyAsBytes = await ReadBytesAsync(stream), DetectedBodyType = BodyType.Bytes, DetectedBodyTypeFromContentType = DetectBodyTypeFromContentType(contentType) }; // Try to get the body as String try { data.BodyAsString = DefaultEncoding.GetString(data.BodyAsBytes); data.Encoding = DefaultEncoding; data.DetectedBodyType = BodyType.String; ```
adam commented 2025-12-29 14:24:00 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Jan 10, 2019):

Yes I see.
Currently changing the code to add MultiPart.

@StefH commented on GitHub (Jan 10, 2019): Yes I see. Currently changing the code to add MultiPart.
adam commented 2025-12-29 14:24:01 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Jan 10, 2019):

See PR
https://github.com/WireMock-Net/WireMock.Net/pull/249
and comment if this is ok.

@StefH commented on GitHub (Jan 10, 2019): See PR https://github.com/WireMock-Net/WireMock.Net/pull/249 and comment if this is ok.
adam commented 2025-12-29 14:24:02 +01:00
Author
Owner
Copy Link

@bgiot commented on GitHub (Jan 10, 2019):

I don't understand what you are going to do by saying "add multipart". Putting back the tests? In fact multipart MUST be seen as binary and NOT string... Otherwise any byte "zero" in the body content will stop the reading of the body. The body must be read as byte[] and not string....

@bgiot commented on GitHub (Jan 10, 2019): I don't understand what you are going to do by saying "add multipart". Putting back the tests? In fact multipart MUST be seen as binary and NOT string... Otherwise any byte "zero" in the body content will stop the reading of the body. The body must be read as byte[] and not string....
adam commented 2025-12-29 14:24:02 +01:00
Author
Owner
Copy Link

@bgiot commented on GitHub (Jan 10, 2019):

I checked your fix. Indeed it's a shortcut. And it should work. But putting back the tests as before is not more backward compatible ?

@bgiot commented on GitHub (Jan 10, 2019): I checked your fix. Indeed it's a shortcut. And it should work. But putting back the tests as before is not more backward compatible ?
adam commented 2025-12-29 14:24:02 +01:00
Author
Owner
Copy Link

@bgiot commented on GitHub (Jan 10, 2019):

I'm ready to validate this new version when available. I'll keep you posted...

@bgiot commented on GitHub (Jan 10, 2019): I'm ready to validate this new version when available. I'll keep you posted...
adam commented 2025-12-29 14:24:02 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Jan 10, 2019):

"add multipart" --> I mean just fixing this code to support your test scenario.

@StefH commented on GitHub (Jan 10, 2019): "add multipart" --> I mean just fixing this code to support your test scenario.
adam commented 2025-12-29 14:24:02 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Jan 10, 2019):

But putting back the tests as before is not more backward compatible ? what you mean by this?

@StefH commented on GitHub (Jan 10, 2019): > But putting back the tests as before is not more backward compatible ? what you mean by this?
adam commented 2025-12-29 14:24:02 +01:00
Author
Owner
Copy Link

@bgiot commented on GitHub (Jan 10, 2019):

The content-type is the key element to decide how to read the body. Trying reading the body as string without checking that the content type is of "text" type can be an issue sometime... no ? I think the way it was done in version 1.4.0.17 is safe. Any special case that needed to remove those checks ? Also in the content-type info you can have the encoding to properly read the body...

@bgiot commented on GitHub (Jan 10, 2019): The content-type is the key element to decide how to read the body. Trying reading the body as string without checking that the content type is of "text" type can be an issue sometime... no ? I think the way it was done in version 1.4.0.17 is safe. Any special case that needed to remove those checks ? Also in the content-type info you can have the encoding to properly read the body...
adam commented 2025-12-29 14:24:03 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Jan 10, 2019):

By that time I changed the code for parsing from the body.
And with that try to read as string, it's easy for users to use the body as string, even if the content-type may be missing or invalid.

For your specific case, it looks like a work-around yes.
I'll just wait for more cases to pop-up and maybe then I need to do a (breaking) change.

@StefH commented on GitHub (Jan 10, 2019): By that time I changed the code for parsing from the body. And with that `try to read as string`, it's easy for users to use the body as string, even if the content-type may be missing or invalid. For your specific case, it looks like a work-around yes. I'll just wait for more cases to pop-up and maybe then I need to do a (breaking) change.
adam commented 2025-12-29 14:24:03 +01:00
Author
Owner
Copy Link

@bgiot commented on GitHub (Jan 10, 2019):

In fact the property DetectedBodyTypeFromContentType is not used afterward (but only is your fix right now for the multipart). I think a test must be added based on that value just before the "try" statement for string/json.

@bgiot commented on GitHub (Jan 10, 2019): In fact the property DetectedBodyTypeFromContentType is not used afterward (but only is your fix right now for the multipart). I think a test must be added based on that value just before the "try" statement for string/json.
adam commented 2025-12-29 14:24:03 +01:00
Author
Owner
Copy Link

@bgiot commented on GitHub (Jan 10, 2019):

notion of "breaking change" ;-) In fact since 1.0.4.18 it was a breaking change ;-) Let's wait indeed for more usecases to see if more changes are needed. Any info about release time for this version 1.0.6.1?
Thanks a lot for your speedy reaction!

@bgiot commented on GitHub (Jan 10, 2019): notion of "breaking change" ;-) In fact since 1.0.4.18 it was a breaking change ;-) Let's wait indeed for more usecases to see if more changes are needed. Any info about release time for this version 1.0.6.1? Thanks a lot for your speedy reaction!
adam commented 2025-12-29 14:24:03 +01:00
Author
Owner
Copy Link

@bgiot commented on GitHub (Jan 10, 2019):

really appreciate your reactivity! Thanks a lot again!

@bgiot commented on GitHub (Jan 10, 2019): really appreciate your reactivity! Thanks a lot again!
adam commented 2025-12-29 14:24:04 +01:00
Author
Owner
Copy Link

@StefH commented on GitHub (Jan 10, 2019):

In a few minutes, the 1.0.6.1`NuGet will be visible.

@StefH commented on GitHub (Jan 10, 2019): In a few minutes, the 1.0.6.1`NuGet will be visible.
adam commented 2025-12-29 14:24:04 +01:00
Author
Owner
Copy Link

@bgiot commented on GitHub (Jan 10, 2019):

I did some tests and all seems to work fine! Good job! Thanks a lot!

@bgiot commented on GitHub (Jan 10, 2019): I did some tests and all seems to work fine! Good job! Thanks a lot!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
bug
doc
doc
duplicate
feature
feature
invalid
pull-request
Mirrored from GitHub Pull Request
 question
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/WireMock.Net-wiremock#162
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?