Re: Proposal: URL API extension, second setter function to allow setting from CURLU object

2023-10-23 Thread Daniel Stenberg via curl-library

On Mon, 23 Oct 2023, Timothe Litt via curl-library wrote:

If you need more than libcurl's features for manipulating URIs, there are 
other C libraries that are widely available, e.g. 
https://uriparser.github.io/ (https://github.com/uriparser/uriparser)


However, if you are using libcurl I *strongly* suggest you use libcurl's 
parser, as it has been shown many times that mixing parsers is a common recipe 
for (security) problems. I blogged about that last year, but I am not the 
first and not the last:


 https://daniel.haxx.se/blog/2022/01/10/dont-mix-url-parsers/

--

 / 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/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


Re: Proposal: URL API extension, second setter function to allow setting from CURLU object

2023-10-23 Thread Timothe Litt via curl-library


On 23-Oct-23 08:28, Mark Gaiser via curl-library wrote:

On Mon, Oct 23, 2023 at 8:57 AM Daniel Stenberg  wrote:

On Sun, 22 Oct 2023, Mark Gaiser via curl-library wrote:

> I get that this is c-code and just the c-way of doing things.
Still, it can
> be simplified a lot, even in c.
>
> I propose a new URL API function with the following signature:
> CURLUcode curl_url_set_o(CURLU *u, CURLUPart what,
>                          const CURLU *source, unsigned int flags)

Assuming you write a lot of code that cherry-picks components from
one URL and
copies them into another, then this looks likes a shortcut yes.
But it also
looks like a kind of function you can easily implement yourself,
using
libcurl's API, in about twenty lines of code or so. 



I'm not firmly against introducing a function like this, but I
think it is
rather specific for a single use case that might not be what most
URL API
users ever need.


Thank you for your insights!
If anyone knows curl, it's you :)

If you think this is probably too specific then it probably is.

If anyone else is interested or knows use cases, share your opinion here.
Else it's gonna stay as an idea to slowly fade away into the corners 
of the mailing list.


If you need more than libcurl's features for manipulating URIs, there 
are other C libraries that are widely available, e.g. 
https://uriparser.github.io/ (https://github.com/uriparser/uriparser)



Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.





OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


Re: Proposal: URL API extension, second setter function to allow setting from CURLU object

2023-10-23 Thread Mark Gaiser via curl-library
On Mon, Oct 23, 2023 at 8:57 AM Daniel Stenberg  wrote:

> On Sun, 22 Oct 2023, Mark Gaiser via curl-library wrote:
>
> > I get that this is c-code and just the c-way of doing things. Still, it
> can
> > be simplified a lot, even in c.
> >
> > I propose a new URL API function with the following signature:
> > CURLUcode curl_url_set_o(CURLU *u, CURLUPart what,
> >  const CURLU *source, unsigned int flags)
>
> Assuming you write a lot of code that cherry-picks components from one URL
> and
> copies them into another, then this looks likes a shortcut yes. But it
> also
> looks like a kind of function you can easily implement yourself, using
> libcurl's API, in about twenty lines of code or so.


> I'm not firmly against introducing a function like this, but I think it is
> rather specific for a single use case that might not be what most URL API
> users ever need.
>

Thank you for your insights!
If anyone knows curl, it's you :)

If you think this is probably too specific then it probably is.

If anyone else is interested or knows use cases, share your opinion here.
Else it's gonna stay as an idea to slowly fade away into the corners of the
mailing list.


>
> --
>
>   / 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/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html


Re: Proposal: URL API extension, second setter function to allow setting from CURLU object

2023-10-23 Thread Daniel Stenberg via curl-library

On Sun, 22 Oct 2023, Mark Gaiser via curl-library wrote:

I get that this is c-code and just the c-way of doing things. Still, it can 
be simplified a lot, even in c.


I propose a new URL API function with the following signature:
CURLUcode curl_url_set_o(CURLU *u, CURLUPart what,
 const CURLU *source, unsigned int flags)


Assuming you write a lot of code that cherry-picks components from one URL and 
copies them into another, then this looks likes a shortcut yes. But it also 
looks like a kind of function you can easily implement yourself, using 
libcurl's API, in about twenty lines of code or so.


I'm not firmly against introducing a function like this, but I think it is 
rather specific for a single use case that might not be what most URL API 
users ever need.


--

 / 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/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html