Initial revision

 Date: 1999-08-04

To Think About When Contributing Source Code

 This document is intended to offer some guidelines that can be useful to

 keep in mind when you decide to write a contribution to the project. This

 concerns new features as well as corrections to existing flaws or bugs.

Naming

 Try using a non-confusing naming scheme for your new functions and variable

 names. It doesn't necessarily have to mean that you should use the same as

 in other places of the code, just that the names should be logical,

 understandable and be named according to what they're used for.

Indenting

 Please try using the same indenting levels and bracing method as all the

 other code already does. It makes the source code a lot easier to follow if

 all of it is written using the same style. I don't ask you to like it, I

 just ask you to follow the tradition! ;-)

Commenting

 Comment your source code extensively. I don't see myself as a very good

 source commenter, but I try to become one. Commented code is quality code

 and enables future modifications much more. Uncommented code much more risk

 being completely replaced when someone wants to extend things, since other

 persons' source code can get quite hard to read.

General Style

 Keep your functions small. If they're small you avoid a lot of mistakes and

 you don't accidentaly mix up variables.

Non-clobbering All Over

 When you write new functionality or fix bugs, it is important that you

 don't fiddle all over the source files and functions. Remember that it is

 likely that other people have done changes in the same source files as you

 have and possibly even in the same functions. If you bring completely new

 functionality, try writing it in a new source file. If you fix bugs, try to

 fix one bug at a time and send them as separate patches.

Separate Patches Doing Different Things

 It is annoying when you get a huge patch from someone that is said to fix 511

 odd problems, but discussions and opinions don't agree with 510 of them - or

 509 of them were already fixed in a different way. Then the patcher needs to

 extract the single interesting patch from somewhere within the huge pile of

 source, and that gives a lot of extra work. Preferably, all fixes that

 correct different problems should be in their own patch with an attached

 description exactly what they correct so that all patches can be selectively

 applied by the maintainer or other interested parties.

Document

 Writing docs is dead boring and one of the big problems with many open

 source projects. Someone's gotta do it. It makes it a lot easier if you

 submit a small description of your fix or your new features with every

 contribution so that it can be swiftly added to the package documentation.

Write Access to CVS Repository

 If you are a frequent contributor, or have another good reason, you can of

 course get write access to the CVS repository and then you'll be able to

 check-in all your changes straight into the CVS tree instead of sending all

 changes by mail as patches. Just ask if this is what you'd want.

Date: 19 November 1999

             Frequently Asked Questions about Curl

1. Problems connecting to SSL servers.

  It took a very long time before I could sort out why curl had problems

  to connect to certain SSL servers when using SSLeay or OpenSSL v0.9+.

  The error sometimes showed up similar to:

  16570:error:1407D071:SSL routines:SSL2_READ:bad mac decode:s2_pkt.c:233:

  It turned out to be because many older SSL servers don't deal with SSLv3

  requests properly. To correct this problem, tell curl to select SSLv2 from

  the command line (-2/--sslv2).

  I have also seen examples where the remote server didn't like the SSLv2

  request and instead you had to force curl to use SSLv3 with -3/--sslv3.

2. Does curl support resume?

  Yes. Both ways on FTP, download ways on HTTP.

3. Is libcurl thread safe?

  Yes, as far as curl's own code goes. It does use system calls that often

  aren't thread safe in most environments, such as gethostbyname().

  I am very interested in once and for all getting some kind of report or

  README file from those who have used libcurl in a threaded environment,

  since I haven't and I get this question more and more frequently!

Misc

 - full URL syntax

 - custom maximum download time

 - custom least download speed acceptable

 - multiple URLs

 - guesses protocol from host name unless specified

 - uses .netrc

 - progress bar/time specs while downloading

 - PROXY environment variables support

 - config file support

 - compiles on win32

HTTP

 - GET

 - PUT

 - HEAD

 - POST

 - multipart POST

 - authentication

 - resume

 - follow redirects

 - custom HTTP request

 - cookie get/send

 - custom headers (that can replace internally generated headers)

 - custom user-agent string

 - custom referer string

 - range

 - proxy authentication

 - time conditions

 - via http-proxy

HTTPS (*1)

 - (all the HTTP features)

 - using certificates

 - via http-proxy

FTP

 - download

 - authentication

 - PORT or PASV

 - single file size information (compare to HTTP HEAD)

 - 'type=' URL support

 - dir listing

 - dir listing names-only

 - upload

 - upload append

 - upload via http-proxy as HTTP PUT

 - download resume

 - upload resume

 - QUOT commands

 - simple "range" support

 - via http-proxy

TELNET

 - connection negotiation

 - stdin/stdout I/O

LDAP (*2)

 - full LDAP URL support

DICT

 - extended DICT URL support

GOPHER

 - GET

 - via http-proxy

FILE

 - URL support

        *1 = requires OpenSSL

        *2 = requires OpenLDAP

CHANGES

CONTRIBUTE

FEATURES

FAQ

FILES

INSTALL

LEGAL

MPL-1.0.txt

README

README.curl

README.libcurl

curl.1

*spec

RESOURCES

TODO

maketgz

Makefile.in

Makefile.am

acconfig.h

aclocal.m4

config.guess

config.h.in

config.sub

configure

configure.in

install-sh

missing

mkinstalldirs

reconf

stamp-h.in

perl/README

perl/*.pl.in

src/*.[ch]

src/*in

src/*am

src/mkhelp.pl

src/Makefile.vc6

src/*m32

lib/getdate.y

lib/*.[ch]

lib/*in

lib/*am

lib/Makefile.vc6

lib/*m32

include/README

include/curl/*.h