So can you elaborate on why using libcurl's own NTLM powers isn't enough?
Our application acts as a proxy and has option to do NTLM
authentication with server on behalf of clients. Here, we could use
curl's NTLM option without any issues.
Also, our application has another mode in which it acts
On Sun, 15 Jun 2014, Von Hawkins wrote:
Personally, I would find value in having the NSS backend supported by the
buildbots. I got curl to build with NSS on .27, but forgot how (lost build
environment entirely) and now I can't get it working on newer versions.
I assume you talk about a
On Sun, 15 Jun 2014, Alessandro Ghedini wrote:
(let me just remind readers that these are thing people asked for, we don't
necessarily think they are good ideas to do...)
colored output
We can take HTTPie [0] as model here (ignoring the evident bias towards
JSON-based HTTP APIs). The
On Sun, 15 Jun 2014, Michael Osipov wrote:
Better support for windows protocols like ldap and socks
What is that supposed to mean? Those aren't Windows protocols.
I think the user meant that we should support protocols like ldap and socks
better on Windows. But I don't know in which ways
Hi Daniel,
basic docs, like curl_easy_setopt are great.
demanding features, e.g. multi interface, are shot.
furthermore I suspect libcurl users who talk to the library in C are a
minority compared to python, php, etc.
documentation for high level languages is left out of scope.
admittedly
On Sunday, June 15, 2014 09:48:10 Von Hawkins wrote:
Personally, I would find value in having the NSS backend supported by the
buildbots. I got curl to build with NSS on .27, but forgot how (lost build
environment entirely) and now I can't get it working on newer versions.
For my use case I
On Sunday, June 15, 2014 14:23:11 Alessandro Ghedini wrote:
Fix the problem where header files became platform/architecture dependent
(a few years ago), making cross-builds cumbersome even in such a simple
scenario as building 32-bit libcurl on a 64-bit Linux system. It would
seem to be a
On Mon, Jun 16, 2014 at 10:11:16AM +0200, Daniel Stenberg wrote:
On Sun, 15 Jun 2014, Alessandro Ghedini wrote:
HTTPS: Live CRL checking and OCSP.
There's a wishlist bug about this in the Debian bts, and I have briefly
looked into how to implement OCSP (RFC2560) a while back.
We all know
On Mon, Jun 16, 2014 at 10:11:16AM +0200, Daniel Stenberg wrote:
On Sun, 15 Jun 2014, Alessandro Ghedini wrote:
(let me just remind readers that these are thing people asked for, we don't
necessarily think they are good ideas to do...)
Otherwise the suggestions are unfiltered I guess I
On Mon, 16 Jun 2014, Petr Pisar wrote:
We all know OCSP is completely broken and barely a tad bit more than
useless. Browsers don't even implement it much or care about the responses,
Mozilla folks have opposite opinion. They removed CRL support in recent
Firefox and they kept OCSP as the
On Mon, 16 Jun 2014, Alessandro Ghedini wrote:
Why would it have to be done in libcurl? I really can't see how coloring of
text output is any business of libcurl's.
The -i and -v options (the ones outputting headers and such) are
implementented by simply setting CURLOPT_HEADER and
On 16.06.2014 09:49, Daniel Stenberg wrote:
We do NSS builds on Linux pretty frequently so we do keep that build
in shape.
We need volunteers to get the NSS stuff tested and the build polished
on Windows.
I had a Windows NSS build quite some time in order to build it for use
with Pidgin
On 16.06.2014 12:17, Marc Hoersken wrote:
I had a Windows NSS build quite some time in order to build it for use
with Pidgin plugins.
I will try to revive it for public use. :-)
Could someone point me to or provide up-to-date instructions on how to
cross-compile nss and nspr on Debian Linux
WooHoo! Thanks Marc!
From: Marc Hoersken i...@marc-hoersken.de
To: curl-library@cool.haxx.se
Sent: Monday, June 16, 2014 3:17 AM
Subject: Re: NSS builds (was Re: [Survey] What people want us to do next)
On 16.06.2014 09:49, Daniel Stenberg wrote:
We do
On Sun, Jun 15, 2014 at 09:47:01PM +0800, Woods wrote:
I use Curl Library C API to request a Https Url, but got an error of Empty
reply from server. So I used standard Curl command to request the same Url,
and get correct result. I noticed that a major difference from the dump out
information
On Sun, 15 Jun 2014, Michael Osipov wrote:
For instance, someone contributes code and docs and never reviews it again.
RFCs change, or get introduced, wording is bad or simply too much text or
even worse it is not written/implemented the way it should be. For the spots
I do use curl at work,
Daniel Stenberg wrote:
On Fri, 13 Jun 2014, Daniel Stenberg wrote:
http://curl.haxx.se/docs/survey/survey2014.html
Haven't had a chance to look at this and in fact didn't get to the survey,
in part because too many of the questions were phrased in a manner which
made them hard to answer.
Am 16. Juni 2014 bei 16:01:14, Daniel Stenberg
(dan...@haxx.se(mailto:dan...@haxx.se)) schrieb:
On Sun, 15 Jun 2014, Michael Osipov wrote:
For instance, someone contributes code and docs and never reviews it again.
RFCs change, or get introduced, wording is bad or simply too much
Am 2014-05-27 09:12, schrieb Michael-O:
Hi folks,
here is a patch for the configure.ac file which adds non-default GSS-API
support for HP-UX.
The changes and reasons in/for this patch:
HP-UX provides a stoneage-old MIT Kerberos (1.3.5) by default which does not
suit our needs.
The patch
Am 2014-05-27 23:49, schrieb Daniel Stenberg:
On Mon, 26 May 2014, Michael Osipov wrote:
here is a patch which corrects configure.ac to compile against
fbopenssl SPNEGO library.
Thanks for the patch. It looks good except for this little nit:
What's the motivation to force it to use
Am 2014-05-27 23:55, schrieb Daniel Stenberg:
On Mon, 26 May 2014, Michael Osipov wrote:
Due to missing #ifdefs, curl tries to perform SPNEGO auth even if it
has been compiled w/o fbopenssl SPNEGO library. Now, Negotiate works,
if and only if, SPNEGO support has bin compiled in, requiring
On Mon, 16 Jun 2014, Dima Tisnek wrote:
basic docs, like curl_easy_setopt are great.
demanding features, e.g. multi interface, are shot.
What about it isn't documented good enough or is confusing?
furthermore I suspect libcurl users who talk to the library in C are a
minority compared to
On Mon, 16 Jun 2014, Rich Gray wrote:
I've always felt that the callback functions deserve man pages. This would
bring all the API info about setup, invocation timing, calling arguments,
return values and entitlements for each function together in one place. It
would give the user a
On Mon, 16 Jun 2014, Daniel Stenberg wrote:
I've also been wanting to get the *setopt options better documented in a
stand-alone fashion so that we can have a single page for each of them (and
link to them individually in a nicer way).
Here's a taste of what I have in mind. Here's a separate
On Mon, 16 Jun 2014, Daniel Stenberg wrote:
Here's a taste of what I have in mind. Here's a separate man page for
CURLOPT_WRITEFUNCTION:
http://curl.haxx.se/libcurl/c/CURLOPT_WRITEFUNCTION.html
I'll admit I was a bit dubious about the value of splitting these options into
their own man
On Mon, 16 Jun 2014, Kamil Dudka wrote:
Fix the problem where header files became platform/architecture dependent
We do exactly that in Fedora packages, which need to be multilib-ready:
http://pkgs.fedoraproject.org/cgit/curl.git/tree/curlbuild.h
I'm thinking one way to fix this problem
On Mon, 16 Jun 2014, Dan Fandrich wrote:
Since the new format encourages more verbosity, I suggest adding a RETURN
VALUE section, which will be mind-numbingly repetitive for most options, but
should subtly encourage people to actually check the return value. Also, a
DEFAULT VALUE section may
On Mon, Jun 16, 2014 at 09:53:08PM +0200, Daniel Stenberg wrote:
I'm thinking one way to fix this problem with this particular header
file - and get back to a single unified header for all systems, is to
use the curlbuild.h.dist file and just rename that to curlbuild.h.
(and remove
On lun, giu 16, 2014 at 10:35:51 +0200, Kamil Dudka wrote:
A while ago I made the Debian libcurl dev packages (those shipping the
header files) support multi-arch (i.e. the possibility of installing the
same package from multiple architecture at the same time). This didn't
quite work as
On Mon, Jun 16, 2014 at 2:00 PM, Daniel Stenberg dan...@haxx.se wrote:
Here's a taste of what I have in mind. Here's a separate man page for
CURLOPT_WRITEFUNCTION:
Looking good!
I know it's a little early to be nit-picking your rough draft, but
since this may become
the forerunner to several
On Mon, Jun 16, 2014 at 10:29:18PM +0200, Dan Fandrich wrote:
On Mon, Jun 16, 2014 at 09:53:08PM +0200, Daniel Stenberg wrote:
I'm thinking one way to fix this problem with this particular header
file - and get back to a single unified header for all systems, is to
use the curlbuild.h.dist
Hi,
I spent the afternoon fighting with OpenSSL and GnuTLS documentation trying to
add support for OCSP stapling to libcurl.
The result is a mostly-not-working-but-you-get-the-idea implementation for both
the OpenSSL and GnuTLS backends (I haven't even looked at NSS but it shouldn't
be hard).
On Mon, 16 Jun 2014, Jeff Pohlmeyer wrote:
I know it's a little early to be nit-picking your rough draft, but since
this may become the forerunner to several new man pages, here are a few
thoughts...
Thanks!
I also thought the order of some paragraphs were a bit off. Updated:
On Mon, 16 Jun 2014, Alessandro Ghedini wrote:
It'd be easier if curlbuild.h.dist was available in the source tarball
though.
It sort of is already. It is renamed to curlbuild.h by 'maketgz' when the
tarball is created. It just gets overwritten by configure if you run configure
in the
34 matches
Mail list logo
