Body parsing of request breaks odata batch requests

[cryxia]

• VSCode Version: 1.25.1
• OS Version: Windows 10
• REST Client Version: 0.19.0

Sorry, I don't have a good reproduction because I haven't found a public odata server that I can test this out on. However I'll detail the issue below and hopefully I'll find some time to do a fix. I wanted to log this issue so that others can find it.

The problem is that the parsing of the body of some requests is a little broken or out of order which results in odata batch requests being parsed incorrectly. These batch requests are multipart/mixed and inside each part the content looks like another http request.

See here for more details on the odata batch request format
Example request in rest client format:

POST /service/$batch HTTP/1.1 
Host: host 
Content-Type: multipart/mixed; boundary=batch_36522ad7-fc75-4b56-8c71-56071383e77b 

--batch_36522ad7-fc75-4b56-8c71-56071383e77b
Content-Type: application/http 
Content-Transfer-Encoding:binary

GET /service/Customers('ALFKI') 
Host: host

--batch_36522ad7-fc75-4b56-8c71-56071383e77b 
Content-Type: multipart/mixed; boundary=changeset_77162fcd-b8da-41ac-a9f8-9357efbbd621 
Content-Length: ###       

--changeset_77162fcd-b8da-41ac-a9f8-9357efbbd621 
Content-Type: application/http 
Content-Transfer-Encoding: binary 

POST /service/Customers HTTP/1.1 
Host: host  
Content-Type: application/atom+xml;type=entry 
Content-Length: ### 

<AtomPub representation of a new Customer> 

--changeset_77162fcd-b8da-41ac-a9f8-9357efbbd621 
Content-Type: application/http 
Content-Transfer-Encoding:binary 

PUT /service/Customers('ALFKI') HTTP/1.1 
Host: host 
Content-Type: application/json 
If-Match: xxxxx 
Content-Length: ### 

<JSON representation of Customer ALFKI> 

--changeset_77162fcd-b8da-41ac-a9f8-9357efbbd621

--batch_36522ad7-fc75-4b56-8c71-56071383e77b 
Content-Type: application/http 
Content-Transfer-Encoding:binary 

GET service/Products HTTP/1.1 
Host: host 

--batch_36522ad7-fc75-4b56-8c71-56071383e77b

The behaviour that I see that is that not all the body is sent - it appears to stop just before the first http like query in the body. I would expect the whole body to be sent

[Huachao]

@cryxia firstly, I found that there is no request delimiters(###) between requests, secondly, the multipart form data request body doesn't follow the multipart form data schema.

[cryxia]

@Huachao That's the thing, the example above is one request. And it does follow the multipart format structure. There are no delimiters because there is only one :p

Each part is delimited by --batch_36522ad7-fc75-4b56-8c71-56071383e77b per the Content-Type.
Everything between --batch_36522ad7-fc75-4b56-8c71-56071383e77b should be treated as a part and shouldn't be parsed by the rest client.

I know it's confusing because each part is in of itself a valid http request, but that's what odata batch requests are. Multiple http requests batched up in multipart/mixed http request.

[Huachao]

@cryxia The extension doesn't support multipart/mixed content type, I think that's the root cause. I will consider supporting this later. Thanks for your suggestion.

[cryxia]

@Huachao No problem. As I said I was hoping to help out by submitting a change for this when I had time. Thought I'd document it so that others can find this issue and know that someone is looking into it :)

[Huachao]

@cryxia that'll be appreciate. Thanks in advance.

[kae]

@Huachao

Just for information.
To get "working" solution for multipart/mixed content type in request (it was working at least in one case with my web api) I replaced function directly at extension installation directory in file mimeUtility.js

    static isMultiPartFormData(contentTypeString) {
        if (!contentTypeString) {
            return false;
        }
        return MimeUtility.parse(contentTypeString).type === 'multipart/form-data';
    }

with

    static isMultiPartFormData(contentTypeString) {
        if (!contentTypeString) {
            return false;
        }
        return MimeUtility.parse(contentTypeString).type === 'multipart/form-data'
        	|| MimeUtility.parse(contentTypeString).type === 'multipart/mixed';
    }

At first glance it doesn't looks like it needed any deep additional coding to support at least basic functionality.

[Huachao]

@cryxia @kae thanks for your suggestions, and I have fixed the issue and will publish in next release.

[Huachao]

@cryxia @kae you can try the latest version to verify

[kae]

@Huachao
It works for my requests.
Thanks.

[cryxia]

All working now, thanks!