Public API for starting in the headers-state

[judofyr]

Multipart bodies are almost like a HTTP req/res; they just don't have status line:

------------0xKhTmLbOuNdArY
Content-Disposition: form-data; name="text1"

hallo welt test123

------------0xKhTmLbOuNdArY
Content-Disposition: form-data; name="text2"


------------0xKhTmLbOuNdArY
Content-Disposition: form-data; name="upload"; filename="hello.pl"
Content-Type: application/octet-stream

#!/usr/bin/perl

use strict;
use warnings;

print "Hello World :)\n"

------------0xKhTmLbOuNdArY--

It would be nice if it was possible parse these headers (the body would just appear as a streaming/EOF-detected body) using http-parser.

[bnoordhuis]

It's a reasonable request but I don't think it's possible to implement.

Multipart body parts are separated by a boundary marker that http-parser would need to scan for. The parser doesn't backtrack so a partial false positive could lead to data being dropped, particularly if the message is spread out over several chunks. To illustrate:

HTTP/1.1 200 OK
Content-Type: multipart/mixed; boundary="marker"

---marker
Content-Type: text/plain

foo
---mar<BREAK>quee
bar
---marker--

The <BREAK> here is the chunk boundary. The parser has seen (but not stored!) ---mar in the previous chunk. When it starts parsing the second chunk, it discovers it's not actually parsing a boundary marker but by then it's too late.

[judofyr]

I'm not suggesting that http-parser would scan for boundaries. On the contrary; I want to scan for boundaries. I would create a new http-parser and only give it this:

Content-Type: text/plain

foo

[bnoordhuis]

Right, that would be fairly easy to implement but it doesn't seem like there's a need for it. Create a new parser, feed it a trivial HTTP/1.1 200 OK status line, then feed it the multipart body, done.

[pgriess]

Agreed; closing.

[tdecaluwe]

Feeding it a status line is indeed a simple workaround, but a bit of a hacky solution. Would you accept a PR for this?

[indutny]

@tdecaluwe I don't think that it is a good idea. Through recent years, we have refactored http-parser pretty significantly internally, and exposing these states will lock us into a particular API just for this use-case.

Sorry, but won't fix.