Hi Tim,

On Tue, May 14, 2019 at 08:57:55PM +0200, Tim Duesterhus wrote:
> Okay, I did a sweep through the configuration parser and:
> 
> 1. Made deprecated directives fatal and removed them from the docs. The
>    error messages speak of "HAProxy 2.1", thus it should be merged into
>    some kind of 'next' branch.
> 2. Made deprecated directives actually warn and remove them from the docs
>    as well. No need to document deprecated options, users can simply peek
>    into the old docs. Also the error messages are pretty clear on what
>    needs to be done to fix it.

OK, I think we can take all of these for a next branch indeed. Two of
them, the one adding a warning and the one removing the unused keyword
could be picked for 2.0 if you agree. Also I'll rename them "MEDIUM" as
they do change something in a way that is fixable by configuration,
these are not just functionally equivalent code cleanups.

> What I did not update:
> 
> 1. Usage of deprecated directives in the 'tests' directory. The fact that
>    the tests still use deprecated directives indicates that no one even
>    uses them any more. Maybe these tests should outright be removed?

Many times I thought about removing them. But each time I look at them
I figure that some *might* still be usable. Now that we have the regtests
probably this is not true anymore. I also suspect a few of them are
referenced in the internal state machine tests, and might need to be
completely converted to regtests before being removed.

> 2. 'req*' and 'rsp*'. I remember that they allow some modification that
>    cannot easily be replicated otherwise (but I'll have to check that
>    first).

Sure but practically speaking such modifications do not make sense in
the real world (e.g. rename many header names at once). And the "excuse"
above has been the reason for continually postponing their removal. I'd
instead vote for warning on them in 2.0 and removing them very early in
2.1. If someone has a compelling use case, we'll get some feedback thanks
to the warning and it will still be possible to figure how to implement
a replacement using http-request rules.

> What I wasn't sure about: The 'transparent' directive. It is deprecated in
> the docs, but it does not warn. When taking a look into the configuration
> parser it appears to set different flags compared to 'option transparent'.
> Can you please take a look at this and either add an appropriate warning or
> remove the deprecated note from the docs?

This vaguely reminds me something indeed, I'll need to have a look at
this. We may even discover that one of them is bogus :-)

Thanks,
Willy

Reply via email to