@@ -114,15 +114,15 @@ Library
114
114
There are plenty of entry points to the library, namely each publicly defined
115
115
function that libcurl offers to applications. All of those functions are
116
116
rather small and easy-to-follow. All the ones prefixed with 'curl_easy' are
117
- put in the lib/curl_easy .c file.
117
+ put in the lib/easy .c file.
118
118
119
119
curl_global_init_() and curl_global_cleanup() should be called by the
120
120
application to initialize and clean up global stuff in the library. As of
121
121
today, it can handle the global SSL initing if SSL is enabled and it can init
122
122
the socket layer on windows machines. libcurl itself has no "global" scope.
123
123
124
- All printf()-style functions use the supplied clones in lib/curl_mprintf .c.
125
- This makes sure we stay absolutely platform independent.
124
+ All printf()-style functions use the supplied clones in lib/mprintf .c. This
125
+ makes sure we stay absolutely platform independent.
126
126
127
127
curl_easy_init() allocates an internal struct and makes some initializations.
128
128
The returned handle does not reveal internals. This is the 'SessionHandle'
@@ -137,17 +137,17 @@ Library
137
137
138
138
curl_easy_perform() does a whole lot of things:
139
139
140
- It starts off in the lib/curl_easy .c file by calling Curl_perform() and the
141
- main work then continues in lib/curl_url .c. The flow continues with a call to
140
+ It starts off in the lib/easy .c file by calling Curl_perform() and the main
141
+ work then continues in lib/url .c. The flow continues with a call to
142
142
Curl_connect() to connect to the remote site.
143
143
144
144
o Curl_connect()
145
145
146
146
... analyzes the URL, it separates the different components and connects to
147
147
the remote host. This may involve using a proxy and/or using SSL. The
148
- Curl_resolv() function in lib/curl_hostip .c is used for looking up host
149
- names (it does then use the proper underlying method, which may vary
150
- between platforms and builds).
148
+ Curl_resolv() function in lib/hostip .c is used for looking up host names
149
+ (it does then use the proper underlying method, which may vary between
150
+ platforms and builds).
151
151
152
152
When Curl_connect is done, we are connected to the remote site. Then it is
153
153
time to tell the server to get a document/file. Curl_do() arranges this.
@@ -162,15 +162,15 @@ Library
162
162
Curl_do() makes sure the proper protocol-specific function is called. The
163
163
functions are named after the protocols they handle. Curl_ftp(),
164
164
Curl_http(), Curl_dict(), etc. They all reside in their respective files
165
- (curl_ftp .c, curl_http .c and curl_dict .c). HTTPS is handled by Curl_http()
166
- and FTPS by Curl_ftp().
165
+ (ftp .c, http .c and dict .c). HTTPS is handled by Curl_http() and FTPS by
166
+ Curl_ftp().
167
167
168
168
The protocol-specific functions of course deal with protocol-specific
169
169
negotiations and setup. They have access to the Curl_sendf() (from
170
- lib/curl_sendf .c) function to send printf-style formatted data to the
171
- remote host and when they're ready to make the actual file transfer they
172
- call the Curl_Transfer() function (in lib/curl_transfer .c) to setup the
173
- transfer and returns.
170
+ lib/sendf .c) function to send printf-style formatted data to the remote
171
+ host and when they're ready to make the actual file transfer they call the
172
+ Curl_Transfer() function (in lib/transfer .c) to setup the transfer and
173
+ returns.
174
174
175
175
If this DO function fails and the connection is being re-used, libcurl will
176
176
then close this connection, setup a new connection and re-issue the DO
@@ -184,13 +184,13 @@ Library
184
184
185
185
o Transfer()
186
186
187
- Curl_perform() then calls Transfer() in lib/curl_transfer .c that performs
188
- the entire file transfer.
187
+ Curl_perform() then calls Transfer() in lib/transfer .c that performs the
188
+ entire file transfer.
189
189
190
- During transfer, the progress functions in lib/curl_progress .c are called
191
- at a frequent interval (or at the user's choice, a specified callback
192
- might get called). The speedcheck functions in lib/curl_speedcheck .c are
193
- also used to verify that the transfer is as fast as required.
190
+ During transfer, the progress functions in lib/progress .c are called at a
191
+ frequent interval (or at the user's choice, a specified callback might get
192
+ called). The speedcheck functions in lib/speedcheck .c are also used to
193
+ verify that the transfer is as fast as required.
194
194
195
195
o Curl_done()
196
196
@@ -238,20 +238,20 @@ Library
238
238
HTTP(S)
239
239
240
240
HTTP offers a lot and is the protocol in curl that uses the most lines of
241
- code. There is a special file (lib/curl_formdata .c) that offers all the
242
- multipart post functions.
241
+ code. There is a special file (lib/formdata .c) that offers all the multipart
242
+ post functions.
243
243
244
- base64-functions for user+password stuff (and more) is in (lib/curl_base64 .c)
245
- and all functions for parsing and sending cookies in (lib/curl_cookie .c).
244
+ base64-functions for user+password stuff (and more) is in (lib/base64 .c) and
245
+ all functions for parsing and sending cookies are found in (lib/cookie .c).
246
246
247
247
HTTPS uses in almost every means the same procedure as HTTP, with only two
248
248
exceptions: the connect procedure is different and the function used to read
249
249
or write from the socket is different, although the latter fact is hidden in
250
250
the source by the use of Curl_read() for reading and Curl_write() for writing
251
251
data to the remote server.
252
252
253
- curl_http_chunks .c contains functions that understands HTTP 1.1 chunked
254
- transfer encoding.
253
+ http_chunks .c contains functions that understands HTTP 1.1 chunked transfer
254
+ encoding.
255
255
256
256
An interesting detail with the HTTP(S) request, is the Curl_add_buffer()
257
257
series of functions we use. They append data to one single buffer, and when
@@ -261,7 +261,7 @@ Library
261
261
FTP
262
262
263
263
The Curl_if2ip() function can be used for getting the IP number of a
264
- specified network interface, and it resides in lib/curl_if2ip .c.
264
+ specified network interface, and it resides in lib/if2ip .c.
265
265
266
266
Curl_ftpsendf() is used for sending FTP commands to the remote server. It was
267
267
made a separate function to prevent us programmers from forgetting that they
@@ -270,42 +270,41 @@ Library
270
270
271
271
Kerberos
272
272
273
- The kerberos support is mainly in lib/curl_krb4 .c and lib/curl_security .c.
273
+ The kerberos support is mainly in lib/krb4 .c and lib/security .c.
274
274
275
275
TELNET
276
276
277
- Telnet is implemented in lib/curl_telnet .c.
277
+ Telnet is implemented in lib/telnet .c.
278
278
279
279
FILE
280
280
281
- The file:// protocol is dealt with in lib/curl_file .c.
281
+ The file:// protocol is dealt with in lib/file .c.
282
282
283
283
LDAP
284
284
285
- Everything LDAP is in lib/curl_ldap .c and lib/curl_openldap .c
285
+ Everything LDAP is in lib/ldap .c and lib/openldap .c
286
286
287
287
GENERAL
288
288
289
289
URL encoding and decoding, called escaping and unescaping in the source code,
290
- is found in lib/curl_escape .c.
290
+ is found in lib/escape .c.
291
291
292
292
While transferring data in Transfer() a few functions might get used.
293
- curl_getdate() in lib/curl_parsedate.c is for HTTP date comparisons (and
294
- more).
293
+ curl_getdate() in lib/parsedate.c is for HTTP date comparisons (and more).
295
294
296
- lib/curl_getenv .c offers curl_getenv() which is for reading environment
297
- variables in a neat platform independent way. That's used in the client,
298
- but also in lib/curl_url .c when checking the proxy environment variables.
299
- Note that contrary to the normal unix getenv(), this returns an allocated
300
- buffer that must be free()ed after use.
295
+ lib/getenv .c offers curl_getenv() which is for reading environment variables
296
+ in a neat platform independent way. That's used in the client, but also in
297
+ lib/url .c when checking the proxy environment variables. Note that contrary
298
+ to the normal unix getenv(), this returns an allocated buffer that must be
299
+ free()ed after use.
301
300
302
- lib/curl_netrc .c holds the .netrc parser
301
+ lib/netrc .c holds the .netrc parser
303
302
304
- lib/curl_timeval .c features replacement functions for systems that don't have
303
+ lib/timeval .c features replacement functions for systems that don't have
305
304
gettimeofday() and a few support functions for timeval conversions.
306
305
307
306
A function named curl_version() that returns the full curl version string is
308
- found in lib/curl_version .c.
307
+ found in lib/version .c.
309
308
310
309
Persistent Connections
311
310
======================
@@ -409,10 +408,10 @@ API/ABI
409
408
Client
410
409
======
411
410
412
- main() resides in src/tool_main .c together with most of the client code.
411
+ main() resides in src/main .c together with most of the client code.
413
412
414
413
src/tool_hugehelp.c is automatically generated by the mkhelp.pl perl script
415
- to display the complete "manual" and the src/tool_urlglob .c file holds the
414
+ to display the complete "manual" and the src/urlglob .c file holds the
416
415
functions used for the URL-"globbing" support. Globbing in the sense that
417
416
the {} and [] expansion stuff is there.
418
417
@@ -421,23 +420,23 @@ Client
421
420
control after the curl_easy_perform() it cleans up the library, checks status
422
421
and exits.
423
422
424
- When the operation is done, the ourWriteOut() function in
425
- src/tool_writeout.c may be called to report about the operation. That
426
- function is using the curl_easy_getinfo() function to extract useful
427
- information from the curl session.
423
+ When the operation is done, the ourWriteOut() function in src/writeout.c may
424
+ be called to report about the operation. That function is using the
425
+ curl_easy_getinfo() function to extract useful information from the curl
426
+ session.
428
427
429
428
Recent versions may loop and do all this several times if many URLs were
430
429
specified on the command line or config file.
431
430
432
431
Memory Debugging
433
432
================
434
433
435
- The file lib/curl_memdebug .c contains debug-versions of a few functions.
436
- Functions such as malloc, free, fopen, fclose, etc that somehow deal with
437
- resources that might give us problems if we "leak" them. The functions in
438
- the memory tracking system do nothing fancy, they do their normal function
439
- and then log information about what they just did. The logged data can then
440
- be analyzed after a complete session,
434
+ The file lib/memdebug .c contains debug-versions of a few functions. Functions
435
+ such as malloc, free, fopen, fclose, etc that somehow deal with resources
436
+ that might give us problems if we "leak" them. The functions in the memdebug
437
+ system do nothing fancy, they do their normal function and then log
438
+ information about what they just did. The logged data can then be analyzed
439
+ after a complete session,
441
440
442
441
memanalyze.pl is the perl script present in tests/ that analyzes a log file
443
442
generated by the memory tracking system. It detects if resources are
0 commit comments