[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22044: 24.4; url-expand.el and url-parse.el not conforming to RFC 39
From: |
Alain Schneble |
Subject: |
bug#22044: 24.4; url-expand.el and url-parse.el not conforming to RFC 3986 |
Date: |
Sat, 28 Nov 2015 22:53:39 +0100 |
url-expand.el and url-parse.el seem to not conform to RFC 3986 "Uniform
Resource Identifier (URI): Generic Syntax" in some cases. But I assume
they should. Here is a list of issues found in url-expand-file-name
and url-generic-parse-url, respectively:
1. resolving relative "fragment-only" URIs against a given absolute
base URI (see RFC3986, section 5. Reference Resolution, and
especially 5.2.2. Transform References):
(url-expand-file-name "#s" "http://a/b/c/d;p?q")
=> "#s" but should be http://a/b/c/d;p?q#s"
(url-expand-file-name "#bar" "http://host")
=> "#bar" but should be "http://host#bar"
(url-expand-file-name "#bar" "http://host/")
=> "#bar" but should be "http://host/#bar"
(url-expand-file-name "#bar" "http://host/foo")
=> "#bar" but should be "http://host/foo#bar"
2. resolving relative "query-only" URIs against a given absolute base
URI (see RFC3986, same sections as mentioned in point 1.):
(url-expand-file-name "?y" "http://a/b/c/d;p?q")
=> "http://a/b/c/?y" but should be "http://a/b/c/d;p?y"
(url-expand-file-name "?y" "http://a/b/c/d")
=> "http://a/b/c/?y" but should be "http://a/b/c/d?y")
3. removing dot segments (see RFC3986, section 5.2.4. Remove Dot
Segments):
(url-expand-file-name "/./g" "http://a/b/c/d;p?q")
=> "http://a/./g" but should be "http://a/g"
(url-expand-file-name "/../g" "http://a/b/c/d;p?q")
=> "http://a/../g" but should be "http://a/g"
4. empty fragment information is lost after parsing URI:
(equal (url-generic-parse-url "#")
(url-parse-make-urlobj nil nil nil nil nil "" "" nil nil))
^
=> nil but should be t (fragment component is actually nil instead
of an empty string)
Same issue with URLs having a number sign (#) as suffix:
"/foo/bar#"
"/foo/bar/#"
"http://host#"
"http://host?#"
"http://host?query#"
"http://host/#"
"http://host/?#"
"http://host/?query#"
"http://host/foo#"
"http://host/foo?#"
"http://host/foo?query#"
... and so forth
With the current behavior, the inverse function url-recreate-url
won't be able to reconstruct exactly the same URI. For example:
(url-recreate-url (url-generic-parse-url "#"))
=> "" but should be "#"
Alain
In GNU Emacs 24.4.1 (i686-pc-mingw32)
of 2014-10-24 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Configured using:
`configure --prefix=/c/usr'
Important settings:
value of $LANG: DES
locale-coding-system: cp1252
- bug#22044: 24.4; url-expand.el and url-parse.el not conforming to RFC 3986,
Alain Schneble <=