Daniel Stenberg via curl-library (Mon, 13 Aug 2018 23:37:56 +0200
(CEST)):
>On Mon, 13 Aug 2018, Jan Ehrhardt via curl-library wrote:
>
>> Daniel Stenberg (Thu, 9 Aug 2018 16:55:38 +0200 (CEST)):
>> -#define UPLOAD_BUFSIZE CURL_MAX_WRITE_SIZE
>> +#define UPLOAD_BUFSIZE (512*1024)
>>
>> @Daniel
On Mon, 13 Aug 2018, Jan Ehrhardt via curl-library wrote:
Daniel Stenberg (Thu, 9 Aug 2018 16:55:38 +0200 (CEST)):
-#define UPLOAD_BUFSIZE CURL_MAX_WRITE_SIZE
+#define UPLOAD_BUFSIZE (512*1024)
@Daniel Stenberg: is there a reason that is stopping you from changing this
in curl?
Yes. (Pretty
Daniel Jelinski via curl-library (Tue, 7 Aug 2018 23:11:25 +0200):
>I recently started using HTTPS functionality with libcurl + openSSL; I
>noticed that by default this combo does not use Windows certificates,
>but instead wants to load them from CA bundle.
I happened to notice that recent X64
https://curl.haxx.se//mail/lib-2018-08/0137.html
myLC--- via curl-library wrote:
Hello, :-)
I'm new to (lib)curl. I decided that this was the most
complete network implementation, after ditching Qt for
continuous multithreading issues.
I would like to know how we can retrieve all the IP
Daniel Stenberg (Thu, 9 Aug 2018 16:55:38 +0200 (CEST)):
-#define UPLOAD_BUFSIZE CURL_MAX_WRITE_SIZE
+#define UPLOAD_BUFSIZE (512*1024)
@Daniel Stenberg: is there a reason that is stopping you from changing
this in curl?
--
Jan
---
On Mon, 13 Aug 2018, myLC--- via curl-library wrote:
With a callback you'd make sure that the user takes care of it when the data
becomes available in that format - and only then.
Yes, but since we need to copy the entire data to the export struct, keeping
that memory around a little longer
On Mon, Aug 13, 2018 at 09:44:53AM +0200, Daniel Stenberg wrote:
> On Mon, 13 Aug 2018, Dan Fandrich via curl-library wrote:
> >I think there should be a new option for this kind of encoding so the
> >canonical form stays canonical for every URI scheme, but programs that
> >would prefer merely a
On 08/13/2018 12:24 PM, Daniel Stenberg wrote:
> ...
> Sure, I'm not totally against a callback. But we'd still have to convert
> the representation to something that we think we can stick to for the
> foreseeable future even if the internals would change...
I do not really care what the
Hi,
The three github respositories named in the subject are now living in the curl
organization instead of under me personally on github.
It should make them more easily discoverable and accessible. I figure they're
better handled by the curl community at large.
They're all ready to
On Mon, 13 Aug 2018, myLC--- via curl-library wrote:
I think most existing users would presume such data to become available via
curl_easy_getinfo(), like the primary IP and friends already are.
I'm obvious not that acquainted with curl. I took a glance at the source.
Unless I'm mistaken,
myLC---wrote:
at the source. Unless I'm mistaken, you are using a renamed
addrinfo struct on the inside.
Could it lead to problems with multiple threads, if you
simply passed a pointer to that (chain of) struct(s) via
curl_easy_getinfo?
It's copied to an internal structure inside
On 08/12/2018 06:55 PM, Daniel Stenberg wrote:
> ...
> We wouldn't expose internals, either way. If we would
> provide the data in an array or struct somehow, that would
> be made specifically for exporting purposes. That would be
> no difference between providing the data in a callback or
>
On Mon, 13 Aug 2018, Dan Fandrich via curl-library wrote:
I think you're right, it should work. Documenting
(CURLU_URLDECODE|CURLU_URLENCODE) as performing canonicalization is probably
all you'd need, besides ensuring decode and encode happen in the correct
order.
We could perhaps even make
13 matches
Mail list logo
