Michael Del Monte added the comment:
Given that obs-fold is technically valid, then can I recommend reading the
entire header first (reading to the first blank line) and then tokenizing the
individual headers using a regular expression rather than line by line? That
would solve the problem
Michael Del Monte added the comment:
... or perhaps
if ':' in line and line[0] != ':':
to avoid the colon-as-first-char bug that plagued this library earlier, though
the only ill-effect of leaving it alone would be a header with a blank key; not
the end of the world
Michael Del Monte added the comment:
I don't want to speak out of school and you guys certainly know what you're
doing, but it seems a shame to go through these gyrations -- lookahead plus
unreading lines -- only to preserve the ability to parse email headers, when
HTTP really does follow
New submission from Michael Del Monte:
Initially reported at https://github.com/kennethreitz/requests/issues/2622
Closely related to http://bugs.python.org/issue19996
An HTTP response with an invalid header line that contains non-blank characters
but *no* colon (contrast http
Michael Del Monte added the comment:
Thanks. Also I meant to have said, ...to terminate only on a *blank*
non-header non-comment line, in accordance with RFC 2616 (and 7230).
I note that the RFCs require CRLF to terminate but in my experience you can get
all manner of blank lines, so
New submission from Michael Del Monte:
Easily reproduced:
re.sub('x', 'a', x*20, re.S)
returns ''
--
components: Regular Expressions
messages: 230216
nosy: ezio.melotti, mgdelmonte, mrabarnett
priority: normal
severity: normal
status: open
title: re.sub does only
