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: Feature request: extend CURLOPT_RESOLVE to allow adding non-permanent DNS cache entries
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Groke, Paul via curl-library <curl-library_at_cool.haxx.se>
Date: Wed, 18 Nov 2020 15:05:31 +0000
On Wed, 18 Nov 2020, Daniel Stenberg wrote:
> Exactly how to extend the format can of course be further discussed. I think I would prefer a slighly more descriptive text, like perhaps ":temp" - and we could then introduce that extra field for further instructions if we want to later on.
> ...
> We should just make sure that we don't shut the door for doing it in the future.
OK. So ... do you mean we extend the format so that if the string starts with a colon, there's a first part that contains options/switches. And the only option currently defined is "temp".
Did you mean it like that? Or did you mean to append ":temp"? If so, I don't really like the idea of using ":" as a delimiter after a field (address-list) that can contain ":" (e.g. in IPv6 literals). While it would be possible for ":temp" because IP literals cannot contain alphabet characters, I don't really like that idea.
So assuming you meant ":temp" as a prefix, the 3 formats would be:
host:port:<address-list>
-host:port:<address-list>
and the new
:<option-list>:host:port:<address-list>
When extending this later, one would need a way to separate different options in the option list.
One way would be
:switch_option,value_option=123:host:port:<address-list>
That would be OK, but I wouldn't want to write the parsing code for it :)
Another way to extend it would be
:switch_option::value_option=123:host:port:<address-list>
Which would be much easier to parse, even though it has a peculiar rule for the end of the option list (colon not followed by another colon).
Another easy to parse format would be
/switch_option/value_option=123/:host:port:<address-list>
Does any one of those sound good?
> Go for it!
Will do, after we agreed on a format :)
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-11-18
Date: Wed, 18 Nov 2020 15:05:31 +0000
On Wed, 18 Nov 2020, Daniel Stenberg wrote:
> Exactly how to extend the format can of course be further discussed. I think I would prefer a slighly more descriptive text, like perhaps ":temp" - and we could then introduce that extra field for further instructions if we want to later on.
> ...
> We should just make sure that we don't shut the door for doing it in the future.
OK. So ... do you mean we extend the format so that if the string starts with a colon, there's a first part that contains options/switches. And the only option currently defined is "temp".
Did you mean it like that? Or did you mean to append ":temp"? If so, I don't really like the idea of using ":" as a delimiter after a field (address-list) that can contain ":" (e.g. in IPv6 literals). While it would be possible for ":temp" because IP literals cannot contain alphabet characters, I don't really like that idea.
So assuming you meant ":temp" as a prefix, the 3 formats would be:
host:port:<address-list>
-host:port:<address-list>
and the new
:<option-list>:host:port:<address-list>
When extending this later, one would need a way to separate different options in the option list.
One way would be
:switch_option,value_option=123:host:port:<address-list>
That would be OK, but I wouldn't want to write the parsing code for it :)
Another way to extend it would be
:switch_option::value_option=123:host:port:<address-list>
Which would be much easier to parse, even though it has a peculiar rule for the end of the option list (colon not followed by another colon).
Another easy to parse format would be
/switch_option/value_option=123/:host:port:<address-list>
Does any one of those sound good?
> Go for it!
Will do, after we agreed on a format :)
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-11-18