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)
|
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.