Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: [PROPOSAL] URL shortcuts
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-users <curl-users_at_lists.haxx.se>
Date: Fri, 21 Jan 2022 22:26:17 +0100 (CET)
On Fri, 21 Jan 2022, Andreas Mohr wrote:
> For development-focussed people maybe, but rather not so much for the wider
> consumer audience.
I don't think that's a proper yardstick to measure things by. A common
question a I get from "consumer audience" persons is in the line of "I used
curl ten years ago and it worked exactly the same, yet you say you work on
curl full time?" - most mortals will stick to using the same few options (from
copy and pasting) and never use anything else. For those users, curl was
probably more or less done feature-wise many years ago.
curl is frequently used by millions of development-focused people. People like
us. Features we add to curl don't need to and cannot be super awesome to every
possible user of it. Yet I think curl itself should keep being super awesome
and I think it remains that by us taking good care of our users.
This said, I'm not saying this change actually will happen and I don't claim
that this is the ultimate syntax for it either. I'm testing the proposal on
you all!
> *) which might easily result from an erroneously empty/non-existent
> hostname-providing **) shell variable! --> silent acceptance (plus
> delivering WRONG results, since the connection to the WRONG host happened to
> work) rather than direct, reliable failure indication [Fail-Fast].
Then I think the script was fragile to begin with. If you want to pass on the
host name in a shell variable and have curl work on a URL based on that, then
just do it:
curl http://$hostname:80/foo/path.html
... if $host ends up a blank (or otherwise contains silly letters etc), then
this will make curl return error because of the broken URL it passes on.
This approach would probably also be a bad way to write in a script unless you
not at the same time have a very rigorous filter/check of the $hostname
variable since if you can include a slash, question mark or a pound sign in
there you can do some serious trickery.
If you do something like:
curl $hostname:80/foo/path.html
Then you *already* have a localhost problem if $hostname "happen" to be set to
a single zero and it opens for cross-protocol tricks if someone manages to
make the host name use a scheme, like: "bla://example.com". Or $hostname could
be set to a zero ("0") and it will connect to localhost.
Date: Fri, 21 Jan 2022 22:26:17 +0100 (CET)
On Fri, 21 Jan 2022, Andreas Mohr wrote:
> For development-focussed people maybe, but rather not so much for the wider
> consumer audience.
I don't think that's a proper yardstick to measure things by. A common
question a I get from "consumer audience" persons is in the line of "I used
curl ten years ago and it worked exactly the same, yet you say you work on
curl full time?" - most mortals will stick to using the same few options (from
copy and pasting) and never use anything else. For those users, curl was
probably more or less done feature-wise many years ago.
curl is frequently used by millions of development-focused people. People like
us. Features we add to curl don't need to and cannot be super awesome to every
possible user of it. Yet I think curl itself should keep being super awesome
and I think it remains that by us taking good care of our users.
This said, I'm not saying this change actually will happen and I don't claim
that this is the ultimate syntax for it either. I'm testing the proposal on
you all!
> *) which might easily result from an erroneously empty/non-existent
> hostname-providing **) shell variable! --> silent acceptance (plus
> delivering WRONG results, since the connection to the WRONG host happened to
> work) rather than direct, reliable failure indication [Fail-Fast].
Then I think the script was fragile to begin with. If you want to pass on the
host name in a shell variable and have curl work on a URL based on that, then
just do it:
curl http://$hostname:80/foo/path.html
... if $host ends up a blank (or otherwise contains silly letters etc), then
this will make curl return error because of the broken URL it passes on.
This approach would probably also be a bad way to write in a script unless you
not at the same time have a very rigorous filter/check of the $hostname
variable since if you can include a slash, question mark or a pound sign in
there you can do some serious trickery.
If you do something like:
curl $hostname:80/foo/path.html
Then you *already* have a localhost problem if $hostname "happen" to be set to
a single zero and it opens for cross-protocol tricks if someone manages to
make the host name use a scheme, like: "bla://example.com". Or $hostname could
be set to a zero ("0") and it will connect to localhost.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-01-21