Proposed IANA registration of the de facto "redis" URI scheme
240 views
Skip to first unread message
Chris Rebert
Jul 16, 2015, 2:04:50 AM7/16/15
to redi...@googlegroups.com
Hi,
I am endeavoring to register the de facto "redis://" URI scheme with
IANA's Uniform Resource Identifier (URI) Schemes registry
(http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml ). I have
written a draft of the registration and am currently seeking feedback on
it prior to officially submitting it to IANA. So I would love to hear
any comments y'all might have on it.
See http://tools.ietf.org/html/rfc3986#section-3 for explanations of
some of the URI terminology that's used in the document.
Please note that the registration is intended merely to describe
existing practice in the wild, rather than to set forth any normative
standard, hence why its Status is Provisional rather than Permanent. (I
think the creation of a normative standard would be great, but it's
beyond the scope of my present work.)
Thanks.
Cheers,
Chris
********
Scheme name: redis
Status: Provisional
Applications/protocols that use this scheme name:
This scheme is used by some Redis database client libraries to
designate the Redis database to connect to, and in some cases to set
additional connection parameters of the client library. Redis client
libraries implement the RESP (REdis Serialization Protocol) defined
in "Redis Protocol specification". This URI scheme is not part of
that specification.
Contact:
Registering party:
Chris Rebert <iana.url.sc...@chrisrebert.com>
Change controller:
Either the registering party, or
Salvatore Sanfilippo <http://invece.org/>
References:
Redis, "Redis Protocol specification", 2015,
<http://redis.io/topics/protocol>.
Redis, "SELECT index", 2015, <http://redis.io/commands/select>.
Redis, "AUTH password", 2015, <http://redis.io/commands/auth>.
Zygmuntowicz, E. and Contributors, "Getting started", 2015, redis-rb,
<https://github.com/redis/redis-rb#getting-started>.
McCurdy, A. and Contributors, "redis.connection.ConnectionPool
.from_url(url, db=None, **kwargs)", redis-py, August 2014,
<https://github.com/andymccurdy/redis-py/blob/2.10.3/redis/connection.py#L733>.
Solem, A. and Contributors, "Using Redis - Celery 3.0.25
documentation", April 2013,
<http://celery.readthedocs.org/en/3.0/getting-started/brokers/redis.html>.
Driessen, V. and Contributors, "Workers: Using a config file - RQ:
Simple job queues for Python", 2015,
<http://python-rq.org/docs/workers/>.
Service Stack LLC and Contributors, "Redis Connection Strings", 2015,
ServiceStack.Redis,
<https://github.com/ServiceStack/ServiceStack.Redis#redis-connection-strings>.
Dollar, D. and Contributors, "redis-url: URL format", 2015,
<https://www.npmjs.com/package/redis-url#url-format>.
Scheme syntax:
Example: redis://:secret@localhost:6379/0?foo=bar&qux=baz
This scheme uses a profile of the RFC 3986 generic URI syntax.
All URI fields after the scheme are optional.
The "userinfo" field uses the traditional "user:password" format.
Expressed using RFC 5234 ABNF, the "path" grammar production from
RFC 3986 is overridden as follows:
path = [ path-slashed ]
; path is optional
path-slashed = "/" [ db-number ]
; exactly zero or one path segments
db-number = "0" / nz-num
; nonnegative decimal integer with no leading zeros
nz-num = NZDIGIT *DIGIT
; positive decimal integer with no leading zeros
NZDIGIT = %x31-39
; the digits 1-9
Scheme semantics:
This scheme is used to designate Redis databases that may be accessed
via RESP.
URIs using this scheme are dereferenced by connecting to the
designated Redis server via RESP and then issuing corresponding AUTH
and/or SELECT commands if a password and/or database number
(respectively) were specified.
If absent, the default value of the "host" URI field is:
"localhost" (or equivalent)
If absent, the default value of the "port" URI field is:
6379
(see the corresponding entry in the Service Name and Transport
Protocol Port Number Registry)
The database number to use for the Redis SELECT command comes from
either the "db-number" portion of the URI (described in the previous
section) or the value from the key-value pair from the "query" URI
field with the key "db". If neither of these are present, the
default database number is 0.
The password to use for the Redis AUTH command comes from either the
password portion of the "userinfo" URI field or the value from the
key-value pair from the "query" URI field with the key "password".
If neither of these are present, the client ought not to issue an
initial AUTH command.
The semantics of other "query" URI field key-value pairs are
implementation-defined.
Encoding considerations:
Unknown, use with care.
Interoperability considerations:
The "fragment" URI field has no known meaning or usage. Unless it
becomes meaningful in the future, omitting it is strongly advised.
Likewise, the username portion of the "userinfo" URI field has no
clear meaning since Redis' optional password-based authentication
does not employ a username. Unless Redis' authentication mechanism
changes in the future, using only the password portion of the
"userinfo" URI field is strongly advised.
The "query" URI field is used to specify client-library-
implementation-specific connection parameters and is therefore not
portable. Using it without knowledge of which specific client
library is going to be used ought to be avoided.
The meaning of "path" URI field values that do not conform to the
"db-number" grammar have no known meaning or usage. Using such
values ought to be avoided.
If both a "db-number" value and a "query" URI field key-value pair
with the key "db" are present, the semantics for what Redis database
number to use are not well-defined. Such situations therefore ought
to be avoided.
If both the password portion of the "userinfo" URI field and a
"query" URI field key-value pair with the key "password" are present,
the semantics for what password to use for authentication are not
well-defined. Such situations therefore ought to be avoided.
Security considerations:
Not fully known, use with care.
As these URIs might contain authentication credentials or designate
Redis servers which allow unauthenticated access, care ought to be
taken to not leak the credentials to unauthorized persons, e.g. by
outputting the URIs in logs or error messages.
I am endeavoring to register the de facto "redis://" URI scheme with
IANA's Uniform Resource Identifier (URI) Schemes registry
(http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml ). I have
written a draft of the registration and am currently seeking feedback on
it prior to officially submitting it to IANA. So I would love to hear
any comments y'all might have on it.
See http://tools.ietf.org/html/rfc3986#section-3 for explanations of
some of the URI terminology that's used in the document.
Please note that the registration is intended merely to describe
existing practice in the wild, rather than to set forth any normative
standard, hence why its Status is Provisional rather than Permanent. (I
think the creation of a normative standard would be great, but it's
beyond the scope of my present work.)
Thanks.
Cheers,
Chris
********
Scheme name: redis
Status: Provisional
Applications/protocols that use this scheme name:
This scheme is used by some Redis database client libraries to
designate the Redis database to connect to, and in some cases to set
additional connection parameters of the client library. Redis client
libraries implement the RESP (REdis Serialization Protocol) defined
in "Redis Protocol specification". This URI scheme is not part of
that specification.
Contact:
Registering party:
Chris Rebert <iana.url.sc...@chrisrebert.com>
Change controller:
Either the registering party, or
Salvatore Sanfilippo <http://invece.org/>
References:
Redis, "Redis Protocol specification", 2015,
<http://redis.io/topics/protocol>.
Redis, "SELECT index", 2015, <http://redis.io/commands/select>.
Redis, "AUTH password", 2015, <http://redis.io/commands/auth>.
Zygmuntowicz, E. and Contributors, "Getting started", 2015, redis-rb,
<https://github.com/redis/redis-rb#getting-started>.
McCurdy, A. and Contributors, "redis.connection.ConnectionPool
.from_url(url, db=None, **kwargs)", redis-py, August 2014,
<https://github.com/andymccurdy/redis-py/blob/2.10.3/redis/connection.py#L733>.
Solem, A. and Contributors, "Using Redis - Celery 3.0.25
documentation", April 2013,
<http://celery.readthedocs.org/en/3.0/getting-started/brokers/redis.html>.
Driessen, V. and Contributors, "Workers: Using a config file - RQ:
Simple job queues for Python", 2015,
<http://python-rq.org/docs/workers/>.
Service Stack LLC and Contributors, "Redis Connection Strings", 2015,
ServiceStack.Redis,
<https://github.com/ServiceStack/ServiceStack.Redis#redis-connection-strings>.
Dollar, D. and Contributors, "redis-url: URL format", 2015,
<https://www.npmjs.com/package/redis-url#url-format>.
Scheme syntax:
Example: redis://:secret@localhost:6379/0?foo=bar&qux=baz
This scheme uses a profile of the RFC 3986 generic URI syntax.
All URI fields after the scheme are optional.
The "userinfo" field uses the traditional "user:password" format.
Expressed using RFC 5234 ABNF, the "path" grammar production from
RFC 3986 is overridden as follows:
path = [ path-slashed ]
; path is optional
path-slashed = "/" [ db-number ]
; exactly zero or one path segments
db-number = "0" / nz-num
; nonnegative decimal integer with no leading zeros
nz-num = NZDIGIT *DIGIT
; positive decimal integer with no leading zeros
NZDIGIT = %x31-39
; the digits 1-9
Scheme semantics:
This scheme is used to designate Redis databases that may be accessed
via RESP.
URIs using this scheme are dereferenced by connecting to the
designated Redis server via RESP and then issuing corresponding AUTH
and/or SELECT commands if a password and/or database number
(respectively) were specified.
If absent, the default value of the "host" URI field is:
"localhost" (or equivalent)
If absent, the default value of the "port" URI field is:
6379
(see the corresponding entry in the Service Name and Transport
Protocol Port Number Registry)
The database number to use for the Redis SELECT command comes from
either the "db-number" portion of the URI (described in the previous
section) or the value from the key-value pair from the "query" URI
field with the key "db". If neither of these are present, the
default database number is 0.
The password to use for the Redis AUTH command comes from either the
password portion of the "userinfo" URI field or the value from the
key-value pair from the "query" URI field with the key "password".
If neither of these are present, the client ought not to issue an
initial AUTH command.
The semantics of other "query" URI field key-value pairs are
implementation-defined.
Encoding considerations:
Unknown, use with care.
Interoperability considerations:
The "fragment" URI field has no known meaning or usage. Unless it
becomes meaningful in the future, omitting it is strongly advised.
Likewise, the username portion of the "userinfo" URI field has no
clear meaning since Redis' optional password-based authentication
does not employ a username. Unless Redis' authentication mechanism
changes in the future, using only the password portion of the
"userinfo" URI field is strongly advised.
The "query" URI field is used to specify client-library-
implementation-specific connection parameters and is therefore not
portable. Using it without knowledge of which specific client
library is going to be used ought to be avoided.
The meaning of "path" URI field values that do not conform to the
"db-number" grammar have no known meaning or usage. Using such
values ought to be avoided.
If both a "db-number" value and a "query" URI field key-value pair
with the key "db" are present, the semantics for what Redis database
number to use are not well-defined. Such situations therefore ought
to be avoided.
If both the password portion of the "userinfo" URI field and a
"query" URI field key-value pair with the key "password" are present,
the semantics for what password to use for authentication are not
well-defined. Such situations therefore ought to be avoided.
Security considerations:
Not fully known, use with care.
As these URIs might contain authentication credentials or designate
Redis servers which allow unauthenticated access, care ought to be
taken to not leak the credentials to unauthorized persons, e.g. by
outputting the URIs in logs or error messages.
Mark Paluch
Jul 16, 2015, 2:47:22 AM7/16/15
to redi...@googlegroups.com, iana.url.sc...@chrisrebert.com
Makes perfectly sense to find a common style.
Itamar Haber
Jul 16, 2015, 2:53:04 AM7/16/15
to redi...@googlegroups.com, iana.url.sc...@chrisrebert.com
Great initiative - well done Chris!
One remark though - although the use of a username isn't supported by Redis ATM, there's an open RCP [1] on the subject. I suggest you include the user identifier in the URI scheme for future compatibility. This also makes sense because current clients that can parse a Redis URI, usually handle the user identifier by ignoring it :)
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.
Itamar Haber | Chief Developers Advocate
Redis Watch Newsletter - Curator and Janitor
Redis Labs - Enterprise-Class Redis for Developers
Mobile: +1 (415) 688 2443
Mobile (IL): +972 (54) 567 9692
Email: ita...@redislabs.com
Twitter: @itamarhaber
Skype: itamar.haber
Chris Rebert
Jul 16, 2015, 4:24:30 AM7/16/15
to Itamar Haber, redi...@googlegroups.com
Hi Itamar,
Thank you for this information! Usernames weren't excluded/prohibited
per se from the URI scheme (mainly because ServiceStack.Redis currently
uses it for apparently unrelated purposes; augh), but there was indeed
verbiage advising against their usage since I had been unaware of them
having any clear potential meaning. Anyway, I have now updated the
document accordingly as follows:
References:
[...]
Sanfilippo, S., "RCP 1 - Multi users AUTH and ACLs for Redis.",
December 2014,
<https://github.com/redis/redis-rcp/blob/master/RCP1.md>.
Scheme semantics:
[...]
+ If a future version of Redis adds support for multi-user
+ authentication (e.g. if RCP1 gets accepted), it's suggested that the
+ username to use when authenticating be obtained from the username
+ portion of the "userinfo" URI field.
Interoperability considerations:
The "fragment" URI field has no known meaning or usage. Unless it
becomes meaningful in the future, omitting it is strongly advised.
- Likewise, the username portion of the "userinfo" URI field has no
- clear meaning since Redis' optional password-based authentication
- does not employ a username. Unless Redis' authentication mechanism
- changes in the future, using only the password portion of the
- "userinfo" URI field is strongly advised.
+ Redis' current optional authentication mechanism does not employ a
+ username, but this might change in the future (e.g. if RCP1 gets
+ accepted). Until/unless that happens: URI producers are advised to
+ leave the username portion of the "userinfo" URI field blank; URI
+ consumers are advised to be aware of the future possibility of
+ non-blank username portions of URIs; attempting to use the username
+ portion of URIs for any purpose other than specifying the username to
+ use when authenticating to the Redis server is strongly advised
+ against.
Security considerations:
[...]
+ If Redis' authentication mechanism adds support for usernames (e.g.
+ if RCP1 gets accepted) in the future, some older services which
+ ignore the username portion of URIs and some newer services which are
+ aware of Redis usernames might interpret a given Redis URI with a
+ username differently from each other. This might make the system
+ vulnerable to privilege escalation or other related attacks.
Thanks again.
Cheers,
Chris
On Wed, Jul 15, 2015, at 11:52 PM, Itamar Haber wrote:
> Great initiative - well done Chris!
>
> One remark though - although the use of a username isn't supported by Redis ATM, there's an open RCP [1] on the subject. I suggest you include the user identifier in the URI scheme for future compatibility. This also makes sense because current clients that can parse a Redis URI, usually handle the user identifier by ignoring it :)
>
> [1]: https://github.com/redis/redis-rcp/blob/master/RCP1.md
>
Thank you for this information! Usernames weren't excluded/prohibited
per se from the URI scheme (mainly because ServiceStack.Redis currently
uses it for apparently unrelated purposes; augh), but there was indeed
verbiage advising against their usage since I had been unaware of them
having any clear potential meaning. Anyway, I have now updated the
document accordingly as follows:
References:
[...]
Sanfilippo, S., "RCP 1 - Multi users AUTH and ACLs for Redis.",
December 2014,
<https://github.com/redis/redis-rcp/blob/master/RCP1.md>.
Scheme semantics:
[...]
+ If a future version of Redis adds support for multi-user
+ authentication (e.g. if RCP1 gets accepted), it's suggested that the
+ username to use when authenticating be obtained from the username
+ portion of the "userinfo" URI field.
Interoperability considerations:
The "fragment" URI field has no known meaning or usage. Unless it
becomes meaningful in the future, omitting it is strongly advised.
- clear meaning since Redis' optional password-based authentication
- does not employ a username. Unless Redis' authentication mechanism
- changes in the future, using only the password portion of the
- "userinfo" URI field is strongly advised.
+ Redis' current optional authentication mechanism does not employ a
+ username, but this might change in the future (e.g. if RCP1 gets
+ accepted). Until/unless that happens: URI producers are advised to
+ leave the username portion of the "userinfo" URI field blank; URI
+ consumers are advised to be aware of the future possibility of
+ non-blank username portions of URIs; attempting to use the username
+ portion of URIs for any purpose other than specifying the username to
+ use when authenticating to the Redis server is strongly advised
+ against.
Security considerations:
[...]
+ If Redis' authentication mechanism adds support for usernames (e.g.
+ if RCP1 gets accepted) in the future, some older services which
+ ignore the username portion of URIs and some newer services which are
+ aware of Redis usernames might interpret a given Redis URI with a
+ username differently from each other. This might make the system
+ vulnerable to privilege escalation or other related attacks.
Thanks again.
Cheers,
Chris
On Wed, Jul 15, 2015, at 11:52 PM, Itamar Haber wrote:
> Great initiative - well done Chris!
>
> One remark though - although the use of a username isn't supported by Redis ATM, there's an open RCP [1] on the subject. I suggest you include the user identifier in the URI scheme for future compatibility. This also makes sense because current clients that can parse a Redis URI, usually handle the user identifier by ignoring it :)
>
> [1]: https://github.com/redis/redis-rcp/blob/master/RCP1.md
>
>> Am Donnerstag, 16. Juli 2015 08:04:50 UTC+2 schrieb Chris Rebert:
>>> Hi,
>>>
>>> I am endeavoring to register the de facto "redis://" URI scheme with
>>> IANA's Uniform Resource Identifier (URI) Schemes registry
>>> (http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml ). I have
>>> written a draft of the registration and am currently seeking feedback on
>>> it prior to officially submitting it to IANA. So I would love to hear
>>> any comments y'all might have on it.
<snip>
>>> Hi,
>>>
>>> I am endeavoring to register the de facto "redis://" URI scheme with
>>> IANA's Uniform Resource Identifier (URI) Schemes registry
>>> (http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml ). I have
>>> written a draft of the registration and am currently seeking feedback on
>>> it prior to officially submitting it to IANA. So I would love to hear
>>> any comments y'all might have on it.
Itamar Haber
Jul 16, 2015, 7:39:50 AM7/16/15
to Chris Rebert, redi...@googlegroups.com
Also - what about rediss:// for SSL? Although this is yet to be included in Redis core, it is currently the de facto standard.
Chris Rebert
Jul 16, 2015, 3:24:07 PM7/16/15
to Itamar Haber, redi...@googlegroups.com
>> >> Am Donnerstag, 16. Juli 2015 08:04:50 UTC+2 schrieb Chris Rebert:
>>> Hi,
>>>
>>> I am endeavoring to register the de facto "redis://" URI scheme with
>>> IANA's Uniform Resource Identifier (URI) Schemes registry
>>> (http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml ). I have
>>> written a draft of the registration and am currently seeking feedback on
>>> it prior to officially submitting it to IANA. So I would love to hear
>>> any comments y'all might have on it.
>> <snip>
<snip>
>>> Hi,
>>>
>>> I am endeavoring to register the de facto "redis://" URI scheme with
>>> IANA's Uniform Resource Identifier (URI) Schemes registry
>>> (http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml ). I have
>>> written a draft of the registration and am currently seeking feedback on
>>> it prior to officially submitting it to IANA. So I would love to hear
>>> any comments y'all might have on it.
>> <snip>
On Thu, Jul 16, 2015, at 04:39 AM, Itamar Haber wrote:
> Also - what about rediss:// for SSL? Although this is yet to be included in Redis core, it is currently the de facto standard.
I'm planning to register it as a follow-up after registering redis://. I
believe a separate registration document will be required, but it should
be pretty trivial since it can mostly just defer to the redis://
registration.
This also reminds me that I ought to add more Security Considerations
related to redis:// traffic being unencrypted. I'll post another diff
after I've done that.
Thanks again,
Chris
Chris Rebert
Jul 16, 2015, 7:30:53 PM7/16/15
to redi...@googlegroups.com
References:
[...]
+ Redis, "Redis Security", 2015, <http://redis.io/topics/security>.
+ Redis, "Redis Encryption", 2015, <http://redis.io/topics/encryption>.
Security considerations:
Not fully known, use with care.
+ an RFC defining RESP, full security considerations for RESP itself
+ are beyond the scope of this document. Considerations in this
+ document will be mostly limited to the redis: URI scheme itself.
+ Some considerations for Redis and RESP may be found in the "Redis
+ Security" and "Redis Encryption" documents.
[...]
+ According to "Redis Security": "Redis is designed to be accessed by
+ trusted clients inside trusted environments. This means that usually
+ it is not a good idea to expose the Redis instance directly to the
+ internet or, in general, to an environment where untrusted clients
+ can directly access the Redis [server]." Accordingly, exposing
+ redis: URIs on the internet or to untrusted clients is not advisable.
[...]
+ "Redis Security" advises the usage of strong and very long passwords
+ to defend against brute-force password-guessing attacks. redis: URIs
+ can therefore be correspondingly long, and users are advised to be
+ prepared to handle very long URIs and password values.
+ redis: URIs may refer to hosts using domain names. The domain name
+ resolution process is subject to its own set of security
+ considerations (RFC 4033).
+ RESP is a simple unencrypted protocol and thus does not provide
+ assurances of confidentiality or data integrity. Combined with
+ RESP's username/password authentication mechanism, the considerations
+ in RFC 3552 (BCP 72), Section 4.1.1 are applicable. "Redis Security"
+ advises the usage of additional specific security measures to help
+ mitigate the weakness of Redis' authentication mechanism.
+ Using RESP over TLS (RFC 5246), as mentioned in "Redis Encryption",
+ along with public key certificates, can provide assurances of peer
+ entity authentication (or merely host authentication if client
+ certificates are not used), confidentiality, and data integrity. It
+ is theoretically possible to use client certificates as an
+ alternative Redis-level authentication/login mechanism in place of
+ the username/password-based "AUTH" RESP command. Apparently named by
+ analogy to HTTPS (RFC 2818), the rediss: URI scheme (yes, two "s"es,
+ not a typo) has been used by some clients to designate RESP over TLS.
+ Other than the usage of TLS, the rediss: URI scheme is not known to
+ have any differences from the redis: URI scheme.
+ redis: URIs may indirectly slightly facilitate denial of service
+ attacks against Redis servers by making it easier to communicate the
+ connection details of targeted Redis servers/databases among systems
+ conducting such attacks.
Cheers,
Chris
Matt Palmer
Jul 16, 2015, 8:31:52 PM7/16/15
to redi...@googlegroups.com
redis+ssl:// or redis+tls:// would be better, IMO. Just tacking an 's' onto
the end of a name that ends in 's' already just looks like a typo.
- Matt
> *Itamar Haber* | Chief Developers Advocate
> *Redis Watch Newsletter <http://redislabs.com/redis-watch-archive> *-
> Curator and Janitor
> *Redis <http://www.redislabs.com/>**Labs <http://www.redislabs.com/>
> *- Enterprise-Class
> Skype: itamar.haber
>
> Blog <http://redislabs.com/blog/> | Twitter
> <https://twitter.com/redislabs> | LinkedIn
> <https://www.linkedin.com/company/redis-labs-inc>
>
> <https://www.redislabs.com/company/redis-labs-careers>
sublanguages in one monolithic executable. It combines the power of C with
the readability of PostScript."
-- Jamie Zawinski
the end of a name that ends in 's' already just looks like a typo.
- Matt
> *Redis Watch Newsletter <http://redislabs.com/redis-watch-archive> *-
> Curator and Janitor
> *Redis <http://www.redislabs.com/>**Labs <http://www.redislabs.com/>
> *- Enterprise-Class
> Redis for Developers
>
> Mobile: +1 (415) 688 2443
> Mobile (IL): +972 (54) 567 9692
> Email: ita...@redislabs.com
> Twitter: @itamarhaber <https://twitter.com/itamarhaber>
>
> Mobile: +1 (415) 688 2443
> Mobile (IL): +972 (54) 567 9692
> Email: ita...@redislabs.com
> Skype: itamar.haber
>
> Blog <http://redislabs.com/blog/> | Twitter
> <https://twitter.com/redislabs> | LinkedIn
> <https://www.linkedin.com/company/redis-labs-inc>
>
> <https://www.redislabs.com/company/redis-labs-careers>
>
> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
> To post to this group, send email to redi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/redis-db.
> For more options, visit https://groups.google.com/d/optout.
--
"[Perl] combines all the worst aspects of C and Lisp: a billion different
> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
> To post to this group, send email to redi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/redis-db.
> For more options, visit https://groups.google.com/d/optout.
--
sublanguages in one monolithic executable. It combines the power of C with
the readability of PostScript."
-- Jamie Zawinski
Chris Rebert
Jul 20, 2015, 6:39:57 PM7/20/15
to redi...@googlegroups.com
On Wed, Jul 15, 2015, at 11:21 AM, Chris Rebert wrote:
> Hi,
>
> I am endeavoring to register the de facto "redis://" URI scheme with
> IANA's Uniform Resource Identifier (URI) Schemes registry
> (http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml ). I have
> written a draft of the registration and am currently seeking feedback on
> it prior to officially submitting it to IANA. So I would love to hear
> any comments y'all might have on it.
> See http://tools.ietf.org/html/rfc3986#section-3 for explanations of
> some of the URI terminology that's used in the document.
>
> Please note that the registration is intended merely to describe
> existing practice in the wild, rather than to set forth any normative
> standard, hence why its Status is Provisional rather than Permanent. (I
> think the creation of a normative standard would be great, but it's
> beyond the scope of my present work.)
>
> Thanks.
>
> Cheers,
> Chris
>
> ********
>
> Scheme name: redis
>
> Status: Provisional
<snip>
> Hi,
>
> I am endeavoring to register the de facto "redis://" URI scheme with
> IANA's Uniform Resource Identifier (URI) Schemes registry
> (http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml ). I have
> written a draft of the registration and am currently seeking feedback on
> it prior to officially submitting it to IANA. So I would love to hear
> any comments y'all might have on it.
> See http://tools.ietf.org/html/rfc3986#section-3 for explanations of
> some of the URI terminology that's used in the document.
>
> Please note that the registration is intended merely to describe
> existing practice in the wild, rather than to set forth any normative
> standard, hence why its Status is Provisional rather than Permanent. (I
> think the creation of a normative standard would be great, but it's
> beyond the scope of my present work.)
>
> Thanks.
>
> Cheers,
> Chris
>
> ********
>
> Scheme name: redis
>
> Status: Provisional
I am happy to report that the IANA registration has been approved!
See http://www.iana.org/assignments/uri-schemes/prov/redis
Cheers,
Chris
Chris Rebert
Jul 22, 2015, 12:19:45 AM7/22/15
to redi...@googlegroups.com
On Mon, Jul 20, 2015, at 03:39 PM, Chris Rebert wrote:
> On Wed, Jul 15, 2015, at 11:21 AM, Chris Rebert wrote:
> > Hi,
> >
> > I am endeavoring to register the de facto "redis://" URI scheme with
> > IANA's Uniform Resource Identifier (URI) Schemes registry
> > (http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml ). I have
> > written a draft of the registration and am currently seeking feedback on
> > it prior to officially submitting it to IANA. So I would love to hear
> > any comments y'all might have on it.
> On Wed, Jul 15, 2015, at 11:21 AM, Chris Rebert wrote:
> > Hi,
> >
> > I am endeavoring to register the de facto "redis://" URI scheme with
> > IANA's Uniform Resource Identifier (URI) Schemes registry
> > (http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml ). I have
> > written a draft of the registration and am currently seeking feedback on
> > it prior to officially submitting it to IANA. So I would love to hear
> > any comments y'all might have on it.
<snip>
> I am happy to report that the IANA registration has been approved!
> See http://www.iana.org/assignments/uri-schemes/prov/redis
I am now happy to report that the follow-up registration of the
> I am happy to report that the IANA registration has been approved!
> See http://www.iana.org/assignments/uri-schemes/prov/redis
"rediss://" (RESP over TLS; the 2nd "S" is for "Secure") URI scheme has
also been approved:
http://www.iana.org/assignments/uri-schemes/prov/rediss
Cheers,
Chris
Arnaud GRANAL
Jul 23, 2015, 11:02:34 AM7/23/15
to redi...@googlegroups.com
Hi,
It seems the case of unix sockets is not covered, this leads to some interesting ambiguity/question which you may find interesting to add on the document:
One suggested syntax could be:
redis://[[user:][password@]]/path/to/socket.sock[/0]
or
redis://[[user:][password@]]/path/to/socket.sock[?db=0]
or
redis://[[user:][password@]]:/path/to/socket.sock[/0]
the first syntax is consistent with what we see with some other projects like connectors for postgresql (c.f. https://github.com/brianc/node-postgres/wiki/pg )
Cheers,
Chris
Mark Paluch
Jul 26, 2015, 1:38:22 PM7/26/15
to Redis DB, ser...@gmail.com
True. I struggled with URI's and sockets when I implemented the support in lettuce.
Your examples point into an interesting direction, but depend a lot on the context where they're used. Let me give some examples:
- redis://path/to/socket is obvious in the first sight, such is redis://path/to/socket/1. But what if your socket is named /path/to/socket/1? Do you still want to select database 1?
- redis://something: Is it something or the name of the socket?
- redis://socket/1: Is it host "socket" and you want to select database 1? Or do you try to resolve host socket and use database 1?
I find it hard to do an assumption on behalf of the context within URI's. All of them are feasible somehow but come at costs of scanning the filesystem or resolving hosts. In this case, "redis+socket" (such as proposed for redis+ssl or redis+tls) would have been very clear.
I ended up with "redis-socket" without the ability to select a database (for now, https://github.com/mp911de/lettuce/blob/master/src/main/java/com/lambdaworks/redis/RedisURI.java#L81). I'll check how other implementations work, I guess, the Python example with "unix://" is the most expressive until now.
Reply all
Reply to author
Forward
0 new messages