Closed Maria-12648430 closed 1 year ago
Was surprized it did not trigger proper test failure, but it seems we don't generate long or non-ascii header parameter values.
Might be nice to update when parser part is also implemented.
I'll have a deeper look bit later today, thank you!
Last commit takes care of an edge case: invalid UTF-8 sequences were not encoded but left as-is. Also added specs.
@seriyps Ok to merge this?
Great work! Sorry for the delay, it was due to UA-RU war.
@seriyps thanks 😄 TBH, I totally forgot about this one 😅
@seriyps I am ok with this being merged.
As pointed out in #310, parameters are supposed to be encoded according to RFC2231, not RFC2047.
The value is first analyzed to decide which representation can/must be used, based on the presence of CTLs, spaces, tspecials, and UTF-8 multibyte characters. Then it is encoded in the selected representation. If the parameter lines become too long (>76 bytes), they are split up according to the continuation scheme described in RFC2231.
In hindsight, getting this right was surprisingly difficult, and therefore a careful review seems to be called for.