Support continuations

[pluma]

If this is meant to become the go-to solution for parsing content-disposition headers, it should ideally support as many optional features as possible.

One that should be relatively easy to support is continuations. See the test case:

attachment; filename*0="foo."; filename*1="html"

should be parsed as:

{type: 'attachment', parameters: {filename: 'foo.html'}}

but is instead parsed as:

{type: 'attachment', parameters: {'filename*0': 'foo.', 'filename*1': 'html'}}

Also note the next test case:

attachment; filename*0*=UTF-8''foo-%c3%a4; filename*1=".html"

This currently results in garbage as the encoding prefix is not parsed.

[dougwilson]

Definitely. It should be added here :)

For some history, I originally decided not to implement it since it was optional, but thought about doing it anyway, but never did since I wasn't sure if anyone actually used it :)

For curiosity, do you happen to know a system/program that is generating them?

[pluma]

Nope, just trying to cover my bases ;)

I think it's more useful to have a single canonical module rather than a dozen diffently broken ones, so I'd prefer to have this feature added here.

[dougwilson]

No problem. I was just curious :) It'll definitely be added!