Summary
uri-path-relative? misunderstands the root path
Metadata
- Id: 16d568cf08387b915c4379cfeb15bed2e26627a9
- Trac id: 997
- Type: defect
- Reporter: andyjpb
- Owner: sjamaan
- Cc:
- Status: closed
- Component: extensions
- Estimated difficulty:
- Resolution: fixed
- Priority: major
- Milestone: someday
- Version: 4.8.x
- Changetime: 2013-03-15 00:35:45 UTC
- Created: 2013-03-14 12:48:25 UTC
- Keywords:
Description
(use uri-common)
#;16> (uri-path-relative? (uri-reference "http://www.knodium.com")) #t #;17> (uri-path-relative? (uri-reference "http://www.knodium.com/")) #f
Changes and comments
[2013-03-14 20:49:00 UTC] sjamaan changed status from new to accepted
[2013-03-14 20:49:00 UTC] sjamaan set owner to sjamaan
[2013-03-14 20:49:00 UTC] sjamaan changed description
[2013-03-14 21:38:11 UTC] sjamaan wrote:
This has been fixed in trunk. Please give it a try.
I didn't really know what to do with the "//foo" case: strictly speaking, this can't be subject to the scheme-based normalization rules of section 6.2.3 (RFC 3986), because we don't have a scheme.
On the other hand, this egg already makes some hard assumptions about the type of URI (for example, it assumes the query part *must* be form-encoded, as key/value pairs) so perhaps this wouldn't be so bad? It would be breaking with the spec, though.
Because I wasn't sure, I kept the behavior the way it was (ie, (uri-path (uri-reference "//foo")) returns '() instead of '(/ ""), making it inconsistent with cases where we do know the scheme).
Perhaps we should be checking that the URI really is a common URI (ie, has a known scheme listed in default-ports), and failing otherwise? This would be obnoxious but possible and prevent more errors being made, but might cause some problems of its own. Gah!
[2013-03-15 00:35:45 UTC] andyjpb changed status from accepted to closed
[2013-03-15 00:35:45 UTC] andyjpb set resolution to fixed
[2013-03-15 00:35:45 UTC] andyjpb wrote:
Super! Thanks!