Daniel Stenberg via curl-library (Thu, 9 Aug 2018 16:55:38 +0200
(CEST)):
>-#define UPLOAD_BUFSIZE CURL_MAX_WRITE_SIZE
>+#define UPLOAD_BUFSIZE (512*1024)
This extra patch also had major speed improvements for Daniel Jelinski's
testcurl.bat. I have now included a fully static
On Sun, Aug 12, 2018 at 06:45:27PM +0200, Daniel Stenberg wrote:
> The current code for the API doesn't offer URL decoding at all when you ask
> for the full URL - since a returned URL is still supposed to be a URL so it
> can't really be "decoded" then. We can of course document that bit to mean
On Sun, 12 Aug 2018, myLC--- via curl-library wrote:
However, I wouldn't be opposed somehow exposing the whole list if someone
would like to work on it.
If this happened through an optional callback after the hostname has been
resolved, you wouldn't have to "expose internals", nor would you
On Sun, 12 Aug 2018, Ray Satiro via curl-library wrote:
I think you overdid it (I know, I'm a little behind on this discussion [1]),
a struct would be simpler.
curl_url_parse(url, );
curl_url_build(parts, );
Is there really a need for a more expansive API?
I don't think exposing such a
On Sun, 12 Aug 2018, Dan Fandrich via curl-library wrote:
I'm curious whether the API can be used to canonicalize a URL, i.e., URL
decode parts that can be decoded without semantic difference but
canonicalize those parts that the specs say must be encoded.
I think it should be possible
The
On 08/11/2018 01:47 PM, Daniel Stenberg wrote:
However, I wouldn't be opposed somehow exposing the
whole list if someone would like to work on it.
If this happened through an optional callback after the
hostname has been resolved, you wouldn't have to "expose
internals", nor would you have to
On 8/1/2018 6:17 PM, Daniel Stenberg wrote:
> In the 2018 user survey, more than 40% of the 395 users who answered
> the question said they'd use a "URL handling" API in libcurl if one
> existed.
>
> I gave it some thoughts the other day and I've now jotted down my
> initial suggestion on how it
