Email list hosting service & mailing list manager

What libraries we need Lassi Kortela (07 Apr 2019 08:55 UTC)
Re: What libraries we need Peter Bex (07 Apr 2019 09:31 UTC)
URI/URL handling Lassi Kortela (07 Apr 2019 10:11 UTC)
Re: URI/URL handling Peter Bex (07 Apr 2019 10:56 UTC)
Re: URI/URL handling Lassi Kortela (07 Apr 2019 12:03 UTC)
Re: URI/URL handling Lassi Kortela (07 Apr 2019 12:46 UTC)
Re: URI/URL handling Peter Bex (07 Apr 2019 14:20 UTC)
Re: URI/URL handling Lassi Kortela (07 Apr 2019 15:06 UTC)
Re: URI/URL handling Peter Bex (07 Apr 2019 15:39 UTC)
Re: URI/URL handling Lassi Kortela (07 Apr 2019 15:52 UTC)
Re: URI/URL handling Peter Bex (07 Apr 2019 16:03 UTC)
Re: URI/URL handling Lassi Kortela (07 Apr 2019 16:30 UTC)
Re: URI/URL handling Arthur A. Gleckler (09 Apr 2019 21:06 UTC)
Re: What libraries we need Arthur A. Gleckler (09 Apr 2019 20:49 UTC)

Re: What libraries we need Arthur A. Gleckler 09 Apr 2019 20:49 UTC

Peter Bex <xxxxxx@more-magic.net> writes:

| The situation is somewhat confusing and weird, but it turns out
to be a good compromise, because whenever you need the
not-fully-decoded path, you can access the underlying uri-generic
object.  As long as you haven't manipulated any component, you
will get back the original input.

I've done the same thing in my URI parser.

I'm sure that your parser is better and more complete, by the way.
I designed mine only to handle URIs that I could imagine my own
server serving, leaving everything else out.  That makes having
this "escape valve" important in case I ever use it in a client or
a proxy or in some other situation where I can't control the form
of the URLs.