Creating URI with relative path renders without slash

[devurandom]

(str (uri/map->URI {:scheme "http"
                    :host   "host"
                    :path   "path"}))
;=> "http://hostpath"

The / slash being missing between host and path is unexpected. I would have expected this to render as http://host/path instead.

[oxalorg]

Looking here: https://datatracker.ietf.org/doc/html/rfc3986#section-3.3

If we only implement a part of the spec (relevant to URLs):

If a URI contains an authority component, then the path component
must either be empty or begin with a slash ("/") character. If a URI
does not contain an authority component, then the path cannot begin
with two slash characters ("//").

+(defn path-when-authority
+  "If a URI contains an authority component, then the path component
+  must either be empty or begin with a slash character."
+  [path]
+  (cond
+    (str/blank? path) path
+    (str/starts-with? path "/") path
+    :else (str "/" path))) ;; or throw?
+
+(defn path-when-no-authority
+  "If a URI does not contain an authority component, then the path
+  cannot begin with two slash characters"
+  [path]
+  (if (str/starts-with? path "//")
+    (throw (ex-info "Path can not start with double slash in the absence of authority." {:path path}))
+    ;; or do an implict strip
+    ;; (subs path 2)
+    path))
+
 (defn uri-str
   "Convert the URI instance back to a string"
   [{:keys [scheme user password host port path query fragment]}]
   (let [authority (authority-string user password host port)]
     (cond-> ""
       scheme    (str scheme ":")
-      authority (str "//" authority)
-      true      (str path)
+      authority (str "//" authority (path-when-authority path))
+      (not authority) (str (path-when-no-authority path))
       query     (str "?" query)
       fragment  (str "#" fragment))))

Need to check if this still adheres to the test cases here: https://www.w3.org/2004/04/uri-rel-test.html

Looking at how others have implemented this, some have chosen to stay true to spec and some have chosen the implict adding of / for convenience (most predictable)

Edit: Hmmm, this makes it so that the defrecord and it's string representations diverge a bit. This could be source for further confusion.

(.path (uri/parse "http://user:password@example.com:8080/path?query=value#fragment")) 
=> "/path"
(.path (uri/->URI "http" "user" "password" "example.com" "8080" "path" "query=value" "fragment"))
=> "path"
;; but both have exact same str repr
(str (uri/parse "http://user:password@example.com:8080/path?query=value#fragment"))
(str (uri/->URI "http" "user" "password" "example.com" "8080" "path" "query=value" "fragment"))
=> "http://user:password@example.com:8080/path?query=value#fragment"

[plexus]

The slash is part of the path. This makes it possible to distinguish http://example.com from http://example.com/, which are two different URIs.

(into {} (uri/uri "https://example.com"))
;; => {:scheme "https",
;;     :user nil,
;;     :password nil,
;;     :host "example.com",
;;     :port nil,
;;     :path nil,
;;     :query nil,
;;     :fragment nil}

(into {} (uri/uri "https://example.com/"))
;; => {:scheme "https",
;;     :user nil,
;;     :password nil,
;;     :host "example.com",
;;     :port nil,
;;     :path "/",
;;     :query nil,
;;     :fragment nil}

So this is by design, if we start implicitly adding / then we can no longer correctly represent the first of these URIs. It would also be a breaking change.

map->URI is the raw record constructor, it's public, you can use it, but then you are on your own to ensure that the result is sensible. The recommend pattern is to start from a base URI, parse it with uri/uri, and then use uri/join and other helpers to further build up the URI you need. join does know about the semantics of path segments and will ensure the missing slash gets added.

(-> (uri/uri "https://example.com")
    (uri/join "path"))
;;=> #lambdaisland/uri "https://example.com/path"

So I don't think any code change is needed, but a clarification in the README could be useful.

[oxalorg]

The slash is part of the path. This makes it possible to distinguish http://example.com from http://example.com/, which are two different URIs.

So this is by design, if we start implicitly adding / then we can no longer correctly represent the first of these URIs. It would also be a breaking change.

This is exactly the case the RFC talks about. Path can either be empty, or if it's non-empty then it must start with a slash. The code above handles this, are there any other class of URIs which we can't represent? 🤔

Does it make sense for only uri-str to be smart about this when printing URLs, or does that make the API more unpredictable?

[plexus]

I think we have to consider URI instances with a non-empty path that doesn't start with a slash as invalid, or you get situations like this

(= (uri/map->URI {:scheme "https" :host "example.com" :path "foo"})
   (uri/map->URI {:scheme "https" :host "example.com" :path "/foo"}))

These two would print the same with your patch if I'm understanding it correctly, but they are not equal, which isn't great. If we really want to allow construction with a path that doesn't start with a slash, and we want to normalize that, then the right time is at construction time, not at serialization time. E.g. you could allow passing a map to uri/uri instead of a string, or add a higher level alternative to map->URI.