Is multipart/mixed with nested application/http supported?

[jods4]

I'm trying to send a multipart/mixed request, that contains nested http requests (this is request batching, e.g. as supported by OData standard).

VS Code seems to be confused by the subrequests -> it shows the run controls on every line that matches an http request, but that's not important.

When I click the topmost request to run it, httpyac goes into a loop with no feedback until something times out eventually.
There's no message on either of the 3 httpyac outputs (console, log, request).
Based on previous experiences with httpyac, my guess is that it crashed while preparing the http request.

[AnWeber]

@jods4 I have not known this format at all. Currently, the parser does not recognize subrequests and the previous request is completed at the subrequest. This is because I try to recognize one request per line and everything that is not a new request is evaluated as the body of the previous request. I wanted to enable a kibana like usage.
You can notice the behavior by the outline view for such a request (using 2.2. Batch Request Body example).

I would now offer that multipart/mixed requests can only be completed explicitly using ###. Detecting the end of the body is rather difficult, as there are too many variants to detect it cleanly

When I click the topmost request to run it, httpyac goes into a loop with no feedback until something times out eventually.

For me, only the first request part is sent. Could it be that your server component then waits for further request parts and produces the timeout?

Based on previous experiences with httpyac, my guess is that it crashed while preparing the http request.

If you have errors, just report them, preferably with example that I can run directly, for example against httpbin.org.

[AnWeber]

multipart/mixed are better supported with v6.6.2. I implemented a rather simple approach to detect the end of the body. It does not include all possible variations like import body from file using < ./body.txt or some string concatenations. Also detecting multipart/mixed using defaultHeaders is not supported.

[jods4]

Thanks, I'm gonna try it out!
It should just work if I end the request with ### right? It think it's reasonable. 👍

Notice that if you detect/parse the Content-Type: multipart/mixed line, the end of request shouldn't be that hard to find.
AFAIK a well-formed multipart request must have boundary=X in its Content-Type as well.
Given that, the end of request body is the line --X-- (modulo some whitespace after?)

The request might not be well-formed at parsing time, so a slightly better strategy is probably to consume all body up to --X-- or ###.

(If you choose to go this route, note that X must be parsed as an http header parameter: it would end at the next ; or could be between ", etc.)

[AnWeber]

Notice that if you detect/parse the Content-Type: multipart/mixed line, the end of request shouldn't be that hard to find.

I have still implemented that :-). However, it would also be possible to import the request body using < ./body.raw. In this case I would have to load the file. But this could also be defined dynamically by variables, or by a few more creative ideas. I try to execute as little as possible at the time of parsing for performance reasons. I have avoided loading files at all costs.

[jods4]

I see, the end of request --boundary-- might be hidden inside an imported file.

So:

• The end of request is always detected by ###.
• If a line --boundary-- comes first in .http file itself, it is treated as the end of request.
• If the --boundary-- is hidden inside an imported file, one must rely on ### above to separate requests.

This all sound very reasonable to me, thanks. 👍

I agree importing files at parsing time is certainly excessive, even if it's just for the multipart edge case.

[AnWeber]

:-) This issue is the reason why it is fun to make this App. I learned something new, Talked about some implementation detail and got some positive Feedback. Thx.