No, the line break wasn't intentional. I ran into this problem on a stock
RedHat 6.2 (intel) system with python 1.5.2 reading pages from an iPlanet
Enterprise Server 4.1 on an NT box. The patch I included fixed the problem
for me. This was a consistent problem for me so I should be able to
reproduce the problem, and I send you any new info I can gather. I'll also
try 2.0b1 with my script to see if it works.
Thanks,
Jim
"Martin v. Loewis"
<martin@loewis.home.cs.tu- To: jbearce@copeland.com
berlin.de> cc: python-dev@python.org
Subject: [ Bug #110662 ] rfc822 (PR#358)
09/17/2000 07:58 AM
Regarding your report in
http://sourceforge.net/bugs/?func=detailbug&bug_id=110662&group_id=5470
I can't reproduce the problem. In 2.0b1,
>>> s="Location:
https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLANID=4&CONTENTPAGEID=0&TengahSession=312442259237-529/2748412123003458168/-1407548368/4/7002/7002/7004/7004\r\n\r\n
"
>>> t=rfc822.Message(cStringIO.StringIO(s))
>>> t['location']
'https://www.website.com:443/tengah/Dpc/vContent.jhtml?page_type=3&PLANID=4&CONTENTPAGEID=0&TengahSession=312442259237-529/2748412123003458168/-1407548368/4/7002/7002/7004/7004'
works fine for me. If the line break between Location: and the URL in
the original report was intentional, rfc822.Message is right in
rejecting the header: Continuation lines must start with white space.
I also cannot see how the patch could improve anything; proper
continuation lines are already supported. On what system did you
experience the problem?
If I misunderstood the report, please let me know.
Regards,
Martin
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