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: Outputting URL components
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stefan Eissing via curl-users <curl-users_at_lists.haxx.se>
Date: Thu, 30 Mar 2023 12:25:23 +0200
> Am 30.03.2023 um 11:22 schrieb Timothe Litt via curl-users <curl-users_at_lists.haxx.se>:
>
>
> On 30-Mar-23 03:28, Daniel Stenberg via curl-users wrote:
>> On Wed, 29 Mar 2023, Rich Gray via curl-users wrote:
>>
>>> If it's not already possible, it seems like it would be useful to give curl a URL solely for the purpose of write outs (no transfer operation). Curl would be able to function as a URL parser for scripts.
>>>
>>> curl --noop http://www.example.com:123/test -w'%{url.port}\n'
>>>
>>> would echo out 123 on a line by itself.
>>>
>>> --noop could also be useful for testing a curl command line for validity without doing a transfer. (Could this speed up some tests?)
>>
>> Yeah, that exact thought crossed my mind as well. I'm hesitating though, because I'm a little afraid of where such an option might take us.
>>
>>
> Hesitation is appropriate.
> This seems rather limited, since you can't get much without doing some (usually network) IO. Resolving a name requires DNS, getting an effective URL requires following redirects, resolving service names to ports requires access to /etc/services, ... and obviously you can't get transfer statistics or most of the other -w parameters.
I am also somewhat hesitant as this `--noop` will either be very limiting or make things more complicated. As in "yes noop, but DNS resolution should happen." "Oh, and maybe the ALPN should be negotiated..."
If a tool to use curl's url parsing to check and construct urls is useful, why not make it another executable on top of libcurl?
> If you're not going to do a transfer, what's the point? Most use cases evaporate on inspection.
> This is rather like the file tests (is a file readable? Writable?) It turns out that while they superficially work, it's pretty common to pass the test but have an actual open fail. And vice-versa. (E.g. where the test uses stat's mode, but there's an ACL. Or an anti-virus block. Or...) The only reliable way to know if an operation will work is to try it.
> It's not clear that curl ought to be a text processor.
> But if you go there anyhow, use a useful name, e.g. --parse-only. The request isn't a NOP. And there are protocols that actually have a NOP operation defined..
>
> Timothe Litt
> ACM Distinguished Engineer
> --------------------------
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed.
>
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
> Etiquette: https://curl.se/mail/etiquette.html
Date: Thu, 30 Mar 2023 12:25:23 +0200
> Am 30.03.2023 um 11:22 schrieb Timothe Litt via curl-users <curl-users_at_lists.haxx.se>:
>
>
> On 30-Mar-23 03:28, Daniel Stenberg via curl-users wrote:
>> On Wed, 29 Mar 2023, Rich Gray via curl-users wrote:
>>
>>> If it's not already possible, it seems like it would be useful to give curl a URL solely for the purpose of write outs (no transfer operation). Curl would be able to function as a URL parser for scripts.
>>>
>>> curl --noop http://www.example.com:123/test -w'%{url.port}\n'
>>>
>>> would echo out 123 on a line by itself.
>>>
>>> --noop could also be useful for testing a curl command line for validity without doing a transfer. (Could this speed up some tests?)
>>
>> Yeah, that exact thought crossed my mind as well. I'm hesitating though, because I'm a little afraid of where such an option might take us.
>>
>>
> Hesitation is appropriate.
> This seems rather limited, since you can't get much without doing some (usually network) IO. Resolving a name requires DNS, getting an effective URL requires following redirects, resolving service names to ports requires access to /etc/services, ... and obviously you can't get transfer statistics or most of the other -w parameters.
I am also somewhat hesitant as this `--noop` will either be very limiting or make things more complicated. As in "yes noop, but DNS resolution should happen." "Oh, and maybe the ALPN should be negotiated..."
If a tool to use curl's url parsing to check and construct urls is useful, why not make it another executable on top of libcurl?
> If you're not going to do a transfer, what's the point? Most use cases evaporate on inspection.
> This is rather like the file tests (is a file readable? Writable?) It turns out that while they superficially work, it's pretty common to pass the test but have an actual open fail. And vice-versa. (E.g. where the test uses stat's mode, but there's an ACL. Or an anti-virus block. Or...) The only reliable way to know if an operation will work is to try it.
> It's not clear that curl ought to be a text processor.
> But if you go there anyhow, use a useful name, e.g. --parse-only. The request isn't a NOP. And there are protocols that actually have a NOP operation defined..
>
> Timothe Litt
> ACM Distinguished Engineer
> --------------------------
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed.
>
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
> Etiquette: https://curl.se/mail/etiquette.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-03-30