[New-bugs-announce] [issue42947] email: Handling when both extended/ascii parameter (filename*/filename) are present?

Florian Bruhin report at bugs.python.org
Sun Jan 17 12:28:07 EST 2021

New submission from Florian Bruhin <python.org at the-compiler.org>:

Consider this reproducer:

    >>> import email.headerregistry
    >>> reg = email.headerregistry.HeaderRegistry()
    >>> parsed = reg('Content-Disposition', """attachment; filename="foo-ae.html"; filename*=UTF-8''foo-%c3%a4.html""")
    >>> parsed.defects
    (InvalidHeaderDefect('duplicate parameter name; duplicate(s) ignored'),)
    >>> parsed.params['filename']

However, the relevant section of RFC 5987 says:


> This specification suggests that a parameter using the extended syntax takes precedence. This would allow producers to use both formats without breaking recipients that do not understand the extended syntax yet.

And RFC 6266 says:


> Many user agent implementations predating this specification do not understand the "filename*" parameter. Therefore, when both "filename" and "filename*" are present in a single header field value, recipients should pick "filename*" and ignore "filename". This way, senders can avoid special-casing specific user agents by sending both the more expressive "filename*" parameter, and the "filename" parameter as fallback for legacy recipients (see Section 5 for an example).

Also see the related attfnboth and attfnboth2 test cases here:

I'm aware those two RFCs are specific to HTTP - but given that there's a "HTTP" policy and "utils.py" has some HTTP-specific date/time handling, I suppose correct handling of this might be in scope as well?

components: Library (Lib)
messages: 385163
nosy: The Compiler
priority: normal
severity: normal
status: open
title: email: Handling when both extended/ascii parameter (filename*/filename) are present?
type: behavior
versions: Python 3.9

Python tracker <report at bugs.python.org>

More information about the New-bugs-announce mailing list