[4suite] [ foursuite-Bugs-1594555 ] Ft.Lib.Uri.SplitUriRef can raise error w/malformed uri

[SourceForge.net]

Bugs item #1594555, was opened at 2006-11-11 03:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428292&aid=1594555&group_id=39954

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 4Lib (Ft.Lib.*)
Group: v1.0b2
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: nikitathespider (nikitathespider)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ft.Lib.Uri.SplitUriRef can raise error w/malformed uri

Initial Comment:
A url that contains a fragment which contains a newline
can cause SplitUriRef to raise an error. The problem is
that the code assumes that the regex
SPLIT_URI_REF_PATTERN "will match every possible
string" (per the code comments) but in this case it
doesn't match. As a result, this direct reference to
.groupdict() fails:
g = SPLIT_URI_REF_PATTERN.match(uriref).groupdict()

Passing this URL to SplitUriRef() demonstrates the problem:
http://example.com/#SpamSausage\nAndMoreSpam

I found that compiling SPLIT_URI_REF_PATTERN with the
re.MULTILINE flag made the problem go away. I realize
that URLs that contain newlines aren't valid anyway,
but I gather that the intent of (and my preference for)
SplitUriRef's behavior is to never raise an error.

I found this in version 1.0 of the code; not 1.0b2 as
reported. (There's no option for v1.0 here in the bug
submission form.)

I have sent millions of URLs through this function and
this is the first time it has failed. Thanks for a
great library! =)

Source code to recreate the problem is attached.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428292&aid=1594555&group_id=39954