Re: Bad date in 1.9.xx SPEC files
Willy, The problem is the ancient version that is supplied, currently 1.5.18. We would find some of the 2.x useful but just don't have the time to fool with manually updating .spec files. Since we are a research institute and use open source to keep our costs low, we have little room to complain and even less influence. Steven Blair
Re: [PATCH] CLEANUP: remove unused functions from openssl-compat level
On Thu, Feb 13, 2020 at 02:19:48PM +0500, Илья Шипицин wrote: > Hello, > > while investigating #429, I've found some unused functions. > let us remove them. > > Cheers, > Ilya Shipitcin Thanks Ilya, applied. -- William Lallemand
Re: [PATCH] MINOR: ssl: add "issuers-chain-path" directive.
On Fri, Feb 14, 2020 at 03:25:48PM +0100, Emmanuel Hocdet wrote: > Hi, > > Is there any hope that this proposal will be considered before HAproxy 2.2? > > ++ > Manu Hello, I'm ok with the feature itself. I'm still not fond of an "auto-discovery" based on the SKID, but I agree that's probably the most convenient way of doing it for the user. The way it's done we won't be able to change the issuers from the CLI easily, but these files don't change too often so that's not a problem at the moment. Can you add a little bit of explanation on how the discovery of the issuer is done in the documentation? I think we will probably need more information in the "show ssl cert" output in the future so the users can debug this kind of feature easily. Thanks, -- William Lallemand
Re: [PATCH] MINOR: ssl: add "issuers-chain-path" directive.
Hi, Is there any hope that this proposal will be considered before HAproxy 2.2? ++ Manu > Le 31 janv. 2020 à 16:06, Emmanuel Hocdet a écrit : > > >> Le 31 janv. 2020 à 12:22, Emmanuel Hocdet a écrit : > >> >> I will send a new patch for « issuers-chain-path » with corrections. >> > > > > <0001-MINOR-ssl-add-issuers-chain-path-directive.patch>
Re: Recommendations for deleting headers by regexp in 2.x?
Hi James, On Fri, Jan 31, 2020 at 12:44:24PM -0800, James Brown wrote: > So how should we move this proposal forward? I'm glad to contribute more > patches... Sorry for the very late response, we needed to discuss this with Christopher then both got busy and then forgot :-/ So after discussion, we both agreed that it makes sense to implement it following the same model as the ACLs described below : > > 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 However, do not feel pressured to implement all matching methods! The currently known ones are described in section 7.1 of the doc, I think that "str", "reg", "sub", "beg" and "end" are the only ones which would make sense over the long term. In practice we could have "str" being the current one and "beg" being the one with the prefix as you need. If later others need more modes we can implement them (unless you want to provide them all at once of course). Thanks for whatever you can do in this area and sorry again for responding late! Willy
