mirror of
https://github.com/moparisthebest/curl
synced 2025-03-01 01:41:50 -05:00
cfbb351e22
- make both libcurl and curl makefiles use register calling convention (previously libcurl had stack calling convention). - added include paths to the Watcom headers so its no longer required to set the environment vars for this. - added -wcd=201 to supress compiler warning about unreachable code. - use macros for all tools, and removed dependency on GNU tools like rm. - make ipv6 and debug builds controlable via env vars and so make them optional instead of default. - commented WINLDAPAPI and WINBERAPI since they broke with OW 1.8, and it seems they're not needed (anymore?). - added rule for hugehelp.c.cvs so that it will be created when not already exist - this is required for building from a release tarball since there we have no hugehelp.c.cvs, thus compilation broke. - removed C_ARG creation from lib/Makefile.Watcom and use CFLAGS directly as done too in src/Makefile.Watcom - this has the benefit that we will see all active cflags and defines during compile. - added LINK-ARG to src/Makefile.Watcom in order to better control linker input. - a couple of other minor makefile tweaks here and there ... - added largefile support for Watcom builds to config-win32.h. Not yet tested if it really works, but should since Win32 supports it. - added loaddll stuff to speed up builds if supported.
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. - We need options to control max pipeline length, and probably how to behave if we reach that limit. As was discussed on the list, it can probably be made very complicated, so perhaps we can think of a way to pass all variables involved to a callback and let the application decide how to act in specific situations. Either way, these fancy options are only interesting to work on when everything is working and we have working apps to test with.