Hi Barry!
I've had some problems with messages which doesn't follow the RFC when
regarding to parameter building. More specificaly, I've found the
following header in a message (in one line):
Content-Type: multipart/mixed;
boundary = b71528a4d486932a8bdd3c50d1048d7c7
This breaks the email package because, following the RFC, there should be no
spaces surrounding the "=" symbol, and the Message class, as expected, breaks
this spliting in "=". OTOH, the RFC defines parameters as follows:
parameter := attribute "=" value
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
value := token / quoted-string
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>
So, there's no chance of finding a space surrounding "=", unless the parameter
is not written as defined in the RFC. Thus, it's safe to strip the name and
value fields.
If you choose to keep following the RFC strictly, I'll understand. OTOH,
parsing bad written headers safely would be nice as well. I can send a patch,
if necessary.
Thanks!
--
Gustavo Niemeyer
[ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4