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.
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:
but is instead parsed as:
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.