Page History

...

Allow the user to specify CIFS storage by way of a URI. This URI will follow RFC 2986 syntax (see: http://tools.ietf.org/html/rfc3986#section-3^{Image Removed}). Specifically, the scheme will be "cifs", the authority will name the server hosting the cifs share, and the path will identify the shared folder. E.g. cifs://192.168.1.128/my_folder

...

Unfortunately, there is no standard for a URI for CIFS. E.g. smb URI never accepted, see https://datatracker.ietf.org/doc/draft-crhertel-smb-url^{Image Removed}

Our alternative to use the existing URI standard, introduce a "cifs" scheme, and encode mount parameters in query parameters.

...

The CIFS hostname can be comfortably accommodated in the host subcomponent of the URI authority (see http://tools.ietf.org/html/rfc3986#section-3.2.2^{Image Removed})

The CIFS share name can be comfortably accommodated by the path path of URI for the share name see (http://tools.ietf.org/html/rfc3986#section-3.3^{Image Removed})

E.g. \\192.168.1.128\CSHV3 becomes cifs://192.168.1.128/CSHV3

The CIFS URI needs to capture additional details not required in NFS. E.g. when using the Linux mount command, the user, password and domain of a CIFS share are specified separately to the remote device path using the '-o' parameter. Http query parameters offer a simple solution to passing this information. Recall that an the URI's query is after the '?' that follows the path, see http://tools.ietf.org/html/rfc3986#section-3.4^{Image Removed} In our case, query parameters will be key=value pairs, linked by '&', values are URL encoded. See http://en.wikipedia.org/wiki/Query_string#URL_encoding^{Image Removed}

E.g. including user=root,password=1pass@word1 would make the URI look like cifs://192.168.1.128/CSHV3?user=root+password=1pass%40word1

Note that username and password are not added to the userinfo section of the URI authority. The URI spec says this is deprecated (see http://tools.ietf.org/html/rfc3986#section-3.2.1^{Image Removed} says it's deprecated.)

...