RFC 7239 Forwarded HTTP Extension

[yadij]

This adds the delete and transparent options as configurable for this extension header in accordance with the RFC. Unlike XFF these operations are enabled in all builds and transparent operation is default. For now adding values still requires custom request_header_add config.

Also adds the basics of a libhttp Config object for HTTP config settings.

Future work:

• upgrading XFF header to Forwarded
• access controls for whether to update Forwarded per-transaction
• 'follow' access controls for setting indirect client IP from this header

[yadij]

For 1 - this is the initial step to make the simple bits configurable and preview the design direction.

For 2 - there is no better design in Squid today and creating a fourth Squid-wide config parser is out of scope here.

For 3 - The broken response behaviour is already being caused by the existing header registration. Not added by anything here. Though true it is not being completely fixed by this PR either.

For 4 - I went with a new directive because this is more of an alternative feature admin have to migrate to selectively when all their software chain supports it than an evolutionary upgrade to XFF. The changed default action, integration of client anonymity, per-parameter configuration requirements and auto-converting of received XFF are all subtly different or cant be passed to legacy XFF software down the chain. The final version of the new directive might be able to absorb the old directive, but admin will probably need them different to handle the headers independently.

I will l try to be on IRC a bit more the next few days and we can go over design plans.

[rousskov]

For the record, I disagree with the first three of the above four arguments. For item 4, more discussion/specifics are needed for me to finalize my opinion. Let's discuss on IRC.