Re: Recommendations for deleting headers by regexp in 2.x?

[James Brown]

So how should we move this proposal forward? I'm glad to contribute more
patches...

On Fri, Jan 24, 2020 at 2:15 AM Willy Tarreau  wrote:

> On Fri, Jan 24, 2020 at 10:26:34AM +0100, Christopher Faulet wrote:
> > Le 24/01/2020 à 09:17, Willy Tarreau a écrit :
> > > On Fri, Jan 24, 2020 at 08:28:33AM +0100, Christopher Faulet wrote:
> > > > Le 23/01/2020 à 19:59, James Brown a écrit :
> > > > > I spent a couple of minutes and made the attached (pretty bad)
> patch to
> > > > > add a del-header-by-prefix.
> > > > >
> > > >
> > > > Just an idea. Instead of adding a new action, it could be cleaner to
> extend
> > > > the del-header action adding some keywords. Something like:
> > > >
> > > >http-request del-header begin-with 
> > > >http-request del-header end-with   
> > > >http-request del-header match  
> > > >
> > > > It could be also extended to replace-header and replace-value
> actions.
> > >
> > > I would also prefer to extend existing syntax, however it's problematic
> > > to insert optional words *before* arguments. This will complicate the
> > > parsing, and even config manipulation scripts.
> > >
> > > That's why I thought we could instead just append an extra optional
> > > keyword appended after the name, eventhough it's less elegant.
> > >
> >
> > From the configuration parsing point of view, it is more or less the same
> > thing. You must test if the second argument is defined or not. And in
> fact,
> > moving it after the header name is not a "better" solution because there
> is
> > an optional condition too at the end. So this one will not be the last
> one.
>
> No, it's more complicated this way because you have to check each and every
> word to figure the syntax. Example: how do you mention that you want to
> remove the header field matching regex "unless" ? You'd have to do this :
>
>  http-request del-header match unless
>
> And it's ambiguous, as it can either mean :
>
>- delete header name "match" unless a condition which needs to be
> parsed,
>  and once figured invalid, you can roll back ;
>- delete header described by regex "unless" with no condition
>
> When you do it the other way around it's way easier, because the name
> always being the first argument makes sure the second one is limited to
> a small subset (match/prefix/if/unless for example):
>
>  http-request del-header unless match
>
> A variant of this could be to use the same syntax as the options we already
> use on ACL matches, which are "-m reg", "-m beg", "-m end". But these will
> also need to be placed after to avoid the same ambiguity (since "-m" is a
> token hence a valid header name). That would give for example :
>
>  http-request del-header server
>  http-request del-header x-private-  -m beg
>  http-request del-header x-.*company -m reg
>  http-request del-header -tracea -m end
>
> Willy
>


-- 
James Brown
Engineer

Re: [PATCH] ssl certificates load speedup and dedup (pem/ctx)

[Emmanuel Hocdet]

Hi William,

> Le 27 janv. 2020 à 16:55, Emmanuel Hocdet  a écrit :
>> 
>> With ‘ssl crt foo.pem chain bar.pem’, or crt-list with ‘foo.pem [chain 
>> bar.pem]’,
>> deduplicate chain look like deduplicate ca-file.
>> Find ocsp_issuer with this chain doesn’t work directly, but it seems doable.
>> For CLI, reload cert when chain is updated seem also complicated, perhaps
>> less problematic than others solutions. 
>> 
> 
> Proposal for ‘chain’ parameter:
> https://github.com/ehocdet/haproxy/commits/chain 
> 
> 

This approach is really too complicated to use and a source of errors.
The first patch alone « issuer-path » ( move to « issuers-chain-path ») really 
do
a better job.
For the possible reload of chain certificates (as you suggested), both are 
equivalent in complexity.
‘set ssl issuers-chain  ’ with « issuers-chain-path » should
accept  only if it's compatible with the stored issuers-chain ()
(via SKID)

I will send a new patch for « issuers-chain-path » with corrections.

++
Manu