1
0
mirror of https://github.com/moparisthebest/curl synced 2025-03-01 09:51:46 -05:00
Steve Holme 520dc64369 build: Fixed no NTLM support for email when CURL_DISABLE_HTTP is defined
USE_NTLM would only be defined if: HTTP support was enabled, NTLM and
cryptography weren't disabled, and either a supporting cryptography
library or Windows SSPI was being compiled against.

This means it was not possible to build libcurl without HTTP support
and use NTLM for other protocols such as IMAP, POP3 and SMTP. Rather
than introduce a new SASL pre-processor definition, removed the HTTP
prerequisite just like USE_SPNEGO and USE_KRB5.

Note: Winbind support still needs to be dependent on CURL_DISABLE_HTTP
as it is only available to HTTP at present.

This bug dates back to August 2011 when I started to add support for
NTLM to SMTP.
2014-11-09 12:54:34 +00:00
..
2014-10-14 09:44:06 +02:00
2013-03-07 11:08:05 +01:00
2014-10-13 16:33:47 +02:00
2013-02-14 10:41:45 +01:00
2012-07-05 22:18:11 +02:00
2014-10-30 23:14:45 +00:00
2014-10-08 12:25:07 +02:00
2014-02-14 08:21:41 +01:00
2010-03-24 11:02:54 +01:00
2014-10-13 16:33:47 +02:00
2014-10-30 23:14:45 +00:00
2014-10-13 16:33:47 +02:00
2013-09-10 23:18:43 +02:00
2013-09-10 23:18:43 +02:00
2014-07-23 09:23:56 +02:00
2014-08-02 23:15:46 +02:00
2013-04-10 16:44:54 +02:00
2014-08-15 21:32:21 +01:00
2014-10-08 12:25:07 +02:00
2014-05-22 00:29:21 +01:00
2010-03-24 11:02:54 +01:00
2011-04-16 00:11:43 +02:00
2014-10-13 16:33:47 +02:00
2014-04-18 22:59:25 +02:00
2013-12-25 23:30:25 +01:00
2014-08-31 23:50:01 +02:00
2014-01-03 12:04:14 +01:00
2014-08-15 21:32:21 +01:00
2010-03-24 11:02:54 +01:00
2014-10-13 16:33:47 +02:00
2013-07-12 12:11:11 +02:00
2013-12-20 17:12:42 +01:00
2014-08-15 21:32:21 +01:00
2014-11-05 12:53:06 +00:00
2013-02-14 10:41:45 +01:00
2013-02-14 10:41:45 +01:00
2013-02-01 08:14:46 +01:00
2013-02-01 08:14:46 +01:00

HTTP Pipelining with libcurl
============================

Background

Since pipelining implies that one or more requests are sent to a server before
the previous response(s) have been received, we only support it for multi
interface use.

Considerations

When using the multi interface, you create one easy handle for each transfer.
Bascially any number of handles can be created, added and used with the multi
interface - simultaneously. It is an interface designed to allow many
simultaneous transfers while still using a single thread. Pipelining does not
change any of these details.

API

We've added a new option to curl_multi_setopt() called CURLMOPT_PIPELINING
that enables "attempted pipelining" and then all easy handles used on that
handle will attempt to use an existing pipeline.

Details

- A pipeline is only created if a previous connection exists to the same IP
  address that the new request is being made to use.

- Pipelines are only supported for HTTP(S) as no other currently supported
  protocol has features resemembling this, but we still name this feature
  plain 'pipelining' to possibly one day support it for other protocols as
  well.

- HTTP Pipelining is for GET and HEAD requests only.

- When a pipeline is in use, we must take precautions so that when used easy
  handles (i.e those who still wait for a response) are removed from the multi
  handle, we must deal with the outstanding response nicely.

- Explicitly asking for pipelining handle X and handle Y won't be supported.
  It isn't easy for an app to do this association. The lib should probably
  still resolve the second one properly to make sure that they actually _can_
  be considered for pipelining. Also, asking for explicit pipelining on handle
  X may be tricky when handle X get a closed connection.