Do we really need to have two almost identical—and slightly inconsistent with each other—documentation sources? I.e. may be it would be better to put all descriptions to the man page, and leave the configuration file with just samples and comments about particular samples (if needed), not about how some option works in general.

I think there are two options now: read out both files, sync, and (a) put the the same description to the both, or (b) move keyword descriptions to man 5 file only.

Related issue: #214 (comment)

I personally vote for simplicity:) I.e. in my opinion it is better to keep keyword descriptions in man 5 file only.

Also, I would prefer to keep the default values in the man 5 file only: if the configuration file contains both samples and default values, then a user might confuse them (especially, a user might think that a value is a default one, when it is just a sample).

At this moment configuration file man page and sample have the same description for Timeout, and it does not mention the default value. To my understanding, the default Timeout value is MAX_IDLE_TIME (600 seconds).

I think it should be clearly stated in the documentation.

If we decide to keep default values in the configuration file, then I propose to comment out this string (i.e. prepend it with #) in the configuration file—600 is the default Timeout value, and setting it explicitly is a bit confusing.

The same reasoning is for MaxClients. As far as I understand, 100 is the default value, so it should be documented, and config line should be prepended with #.

The same question is for LogLevel. The default LogLevel is Info. (And setting Connect leads to emitting a couple of DEBUG messages for some reason…)

tinyproxy.conf file in its LogFile option description contains the following sentence: "If neither Syslog nor LogFile are specified, output goes to stdout." This definitely should be mentioned in the man 5 tinyproxy.conf too.

For the record, DefaultErrorFile has its default value (placeholder) in the fallback_error variable.

Also, in my opinion, the use case for *ErrorFile is not described well enough. The documentation uses term HTTP error, and e.g. both

curl --http1.0 --proxy 'http://localhost:8888' --show-headers --verbose 'http://httpstat.us/500' and

curl --http1.0 --proxy 'http://localhost:8888' --show-headers --verbose 'http://httpstat.us/111'
produce the same 500 Internal Server Error headers, but they do not trigger *ErrorFile usage. On the other had, pure connection error—e.g. attempting to connect to non-existent host or closed port—triggers *ErrorFile usage and generates an error message with the same 500 code (wich is, obviously, correct), but strictly speaking "HTTP error" per se did not occur, DNS resolving or TCP connection error did.

To be clear: yes, I'm going to file a PR for all aforementioned. Of course, I'll ask more questions in the IRC channel:)