search for: rfc3986

According to RFC 3986, ''['' and '']'' are reserved characters. However, Rails 3.0.7 is not escaping them. This is fixed in master by this commit: https://github.com/rails/rails/commit/52b71c01fd3c8a87152f55129a8cb3234190734a Can this fix be included in 3.0.x ? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails:

...4563..1201176e9 100644 --- a/fish/guestfish.pod +++ b/fish/guestfish.pod @@ -1225,6 +1225,16 @@ The equivalent API command would be: ><fs> add /disk protocol:ssh server:tcp:example.com [username:user] +Note that the URIs follow the syntax of +L<RFC 3986|https://tools.ietf.org/html/rfc3986>: in particular, there +are restrictions on the allowed characters for the various components +of the URI. Characters such as C<:>, C<@>, and C</> B<must> be +percent-encoded: + + $ guestfish -a ssh://user:pass%40word@example.com/disk.img + +In this case, the password is...

...gt; quotes -- causes the perms errors I was seeing. > > > > nbd, as I just rm need-to-escape chars from my random-pass-str > generator snippet. > > > > simple enough workaround, once I realized ... > > > > > it looks like there's a parsing error so that rfc3986 compliant %encoding in the user or password field of the url is not accepted by Dovecot. John

I just noticed something interesting (or not) about getting to my RoR app on the 2 browsers. I''ve tested it running Webrick or Mongrel_rails and get the same behavior. The app is at http://www.mydomain.com:myport#/app/list Specifying that complete URL works fine in both browsers. However in IE if you just specify www.mydomain.com:myport#/app/list I get page not found. In FF the URL

...ould >> teach nbdkit to support --run '$uri'). >> > > Oh, I get it now. So "nbd:unix:/path" is a valid URL without authority > where the > path is "unix:/path".  Well, TIL =) > It is nicely visible here: > >  https://tools.ietf.org/html/rfc3986#section-3 > > These patches are fine from my standpoint, although I must say thinking > about > the above as defined in the RFC makes me re-evaluate my feelings about it. > Having URI without authority just use a local file (socket) makes sense > now. Except that our URI proposa...

...tial > packet to further identify the stream data is, as you suggest, > another good idea. I'd make that a SHOULD. > CMML may have more on this (a document I should read properly sometime), but it seems that a way of specifying a logical stream via a URI would be useful too. Within rfc3986 the query or fragment components could be used. Both have problems; fragment prevents us further specifying a fragment within a logical stream, query's meaning seems to be determined by the scheme (also a problem with using part of the path). Fragment would also (as I understand) conflict wit...

...tial > packet to further identify the stream data is, as you suggest, > another good idea. I'd make that a SHOULD. > CMML may have more on this (a document I should read properly sometime), but it seems that a way of specifying a logical stream via a URI would be useful too. Within rfc3986 the query or fragment components could be used. Both have problems; fragment prevents us further specifying a fragment within a logical stream, query's meaning seems to be determined by the scheme (also a problem with using part of the path). Fragment would also (as I understand) conflict wit...

I'm not sure whether we want to go with just the first patch (reject nbd:unix:/path but still accept nbd:/path), or squash the two in order to go with the second (reject both abbreviated forms, and require scheme://...). Either way, though, nbdkit -U - --run '$nbd' will now error out rather than inadvertently connect over TCP to localhost:10809 instead of the intended Unix connection

...--run '$unixsocket', or maybe we should >teach nbdkit to support --run '$uri'). > Oh, I get it now. So "nbd:unix:/path" is a valid URL without authority where the path is "unix:/path". Well, TIL =) It is nicely visible here: https://tools.ietf.org/html/rfc3986#section-3 These patches are fine from my standpoint, although I must say thinking about the above as defined in the RFC makes me re-evaluate my feelings about it. Having URI without authority just use a local file (socket) makes sense now. Even having the unix: prefix to show that it is a UNIX soc...

I believe the implementation of utils::URLencode is non-compliant with RFC 3986, which it claims to implement (http://tools.ietf.org/html/rfc3986). Specifically, its percent encoding uses lowercase letters a-f, which it should use uppercase letters A-F. Here's what URLencode currently produces: library("utils") URLencode("*+,;=:/?", reserved = TRUE) # "%2a%2b%2c%3b%3d%3a%2f%3f" According to RFC 3986 (refe...

On 13/11/2020 21:32, PGNet Dev wrote: > On 11/13/20 11:37 AM, John Fawcett wrote: >>> still dunno why the 401. :-/ >> >> So I just did a quick check of running dovecot with a standalone >> solr-8.7.0 instance and I'm not seeing any issues. > > +1 > >> I confirm I haven't configured anything for indexer or indexer-worker in >> dovecot, just

...umber overflows. Is there anything I'm missing or would a patch which implements that be acceptable? Also could the uri->port field be changed to unsigned int without breaking ABI? Rich. [1] https://github.com/NetworkBlockDevice/nbd/blob/master/doc/uri.md [2] https://tools.ietf.org/html/rfc3986#section-3.2.3 [3] $ cat port.c #include <stdio.h> #include <stdlib.h> #include <stdint.h> #include <inttypes.h> #include <libxml/uri.h> int main (int argc, char *argv[]) { xmlURIPtr uri = xmlParseURI (argv[1]); if (!uri) { fprintf (std...

...ntify the stream data is, as you suggest, >>another good idea. I'd make that a SHOULD. >> > > > CMML may have more on this (a document I should read properly > sometime), but it seems that a way of specifying a logical stream > via a URI would be useful too. Within rfc3986 the query or > fragment components could be used. Both have problems; fragment > prevents us further specifying a fragment within a logical stream, > query's meaning seems to be determined by the scheme (also a > problem with using part of the path). Fragment would also (as I >...