id summary reporter owner description type status priority milestone component version resolution keywords cc difficulty 1019 Different uri-common results for a hairy case Mario Domenech Goulart sjamaan "http://blog.lunatech.com/2009/02/03/what-every-web-developer-must-know-about-url-encoding shows an example of a crazy URI and its corresponding parts after parsing. uri-common's {{{uri-reference}}} seems to parse it differently, producing different results. Here's the case from the aforementioned blog post: {{{ While this is slightly nuts and ""http://example.com/:@-._~!$&'()*+,=;:@-._~!$&'()*+,=:@-._~!$&'()*+,==?/?:@-._~!$'()*+,;=/?:@-._~!$'()*+,;==#/?:@-._~!$&'()*+,;="" is a valid HTTP URL, this is the standard. For the curious, the previous URL expands to: Part Value Scheme http Host example.com Path /:@-._~!$&'()*+,= Path parameter name :@-._~!$&'()*+, Path parameter value :@-._~!$&'()*+,== Query parameter name /?:@-._~!$'()* ,; Query parameter value /?:@-._~!$'()* ,;== Fragment /?:@-._~!$&'()*+,;= }}} Here's what uri-common produces for that uri: {{{ (uri-reference ""http://example.com/:@-._~!$&'()*+,=;:@-._~!$&'()*+,=:@-._~!$&'()*+,==?/?:@-._~!$'()*+,;=/?:@-"") # }}} I'm not sure it is a bug in uri-common. Just filing this ticket because I noticed the difference between uri-common's behavior and the results presented by that blog post." defect closed not urgent at all someday extensions 4.8.x wontfix uri-common