[PATCH] DOC: typo fixes for configuration.txt

[Daniel Corbett]

Hello,


Here's a quick round of typo corrections for configuration.txt


Thanks,
-- Daniel




0001-DOC-configuration-various-typo-fixes.patch
Description: Binary data

AWS and Azure Install Base

[raechel . lambert]

Hi,

I hope this email finds you well.

Would you be interested in targeting the below mentioned applications users
base to enrich your marketing and sales efforts?

Alibaba Cloud

LimeStone

Pivotal

Amazon Web Services

LiquidWeb

Rackspace Cloud

CloudSigma

MassiveGrid

Salesforce

Dell Cloud

Microsoft Azure

SAP

DigitalOcean

Navisite

Verizon Cloud

Google Cloud Platform

OpenNebula

VMware

IBM Cloud

Oracle Cloud

Vultr and more.

We can customize this list as per your specific technology, revenue size of
companies, and job titles from those companies.

I appreciate your time and look forward to hearing from you.

Thanks,

Raechel Lambert| Sr Cloud Specialist

If you don't want to include yourself in our mailing list, please reply
back “unsubscribe” a subject line

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Gersner]

On Mon, Jul 6, 2020 at 4:37 PM Aleksandar Lazic  wrote:

> Should a blank be after '%s'?
>
> +   memprintf(err, "%sthis version of openssl cannot attach
> certificate chain for SSL certificate generation.\n",
> + err && *err ? *err : "");
>
> Looked around in the file and that seemed like the current practice.
It assumes that nested err messages always end with a newline, which makes
sense.


> On 05.07.20 14:09, Gersner wrote:
> > That's my fault. I was aware of the versioning but forgot to wrap in
> ifdef there.
> > Configuration prevents from setting those settings on unsupported
> versions.
> >
> >
> > On Sun, Jul 5, 2020 at 2:57 PM Илья Шипицин  > wrote:
> >
> > https://cirrus-ci.com/task/6191727960653824
> >
> > seems, openssl-1.0.0 (used in CentOS6/RHEL6) does not support those
> methods.
> >
> > haproxy claims to support openssl starting 0.9.8, I guess
> openssl-0.9.8 is rarely tested
> >
> > вс, 5 июл. 2020 г. в 16:48, Gersner  gers...@gmail.com>>:
> >
> > Awesome. I will run the manual tests on the variants later today.
> > Thanks.
> >
> > On Sun, Jul 5, 2020 at 2:45 PM Илья Шипицин <
> chipits...@gmail.com > wrote:
> >
> > if you have tested your code (I'm sure you did), maybe
> manual testing will be simple enough
> > you just need to rebuild haproxy against LibreSSL,
> BoringSSL, older openssl
> >
> > examples how to build ssl lib and build haproxy against it
> might be taken from .travis.yml (I was about to write an article, but I'm
> lazy)
> >
> > вс, 5 июл. 2020 г. в 16:16, Gersner  >:
> >
> > Oh, wasn't aware of that.
> > Is there some automation to test this or should I
> manually verify this?
> >
> >
> > On Sun, Jul 5, 2020 at 2:13 PM Илья Шипицин <
> chipits...@gmail.com > wrote:
> >
> > I recall some issues with LibreSSL and chaining
> trust. Like it was declared but never worked.
> > we'll see that in runtime if there are such issues
> >
> > вс, 5 июл. 2020 г. в 16:06, Илья Шипицин <
> chipits...@gmail.com >:
> >
> > nice, all ssl variants build well
> >
> https://travis-ci.com/github/chipitsine/haproxy/builds/174323866
> >
> > вс, 5 июл. 2020 г. в 15:48, Gersner <
> gers...@gmail.com >:
> >
> >
> >
> > On Sun, Jul 5, 2020 at 1:42 PM Илья Шипицин <
> chipits...@gmail.com > wrote:
> >
> > do you have your patches on github fork ?
> > (I could not find your fork)
> >
> > Yes. See branch
> https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra
> >
> >
> > вс, 5 июл. 2020 г. в 15:13, Gersner <
> gers...@gmail.com >:
> >
> >
> >
> > On Sun, Jul 5, 2020 at 12:28 PM Илья
> Шипицин mailto:chipits...@gmail.com>> wrote:
> >
> > does it clearly applies to
> current master ? either gmail scrambled patch or it is not.
> > can you try please ?
> >
> > Exporting the eml and running 'git
> am' it works cleanly.
> >
> > I've reproduced the exact same
> output when copy-pasting from gmail. It seems gmail converts the tabs to
> spaces and this fails the patch (Not sure why).
> > Running patch with '-l' will resolve
> this, but it's probably safer to run git am on the email.
> >
> >
> > $ patch -p1 < 1.patch
> > patching file
> doc/configuration.txt
> > patching file
> include/haproxy/listener-t.h
> > Hunk #1 FAILED at 163.
> > 1 out of 1 hunk FAILED -- saving
> rejects to file include/haproxy/listener-t.h.rej
> > patching file src/cfgparse-ssl.c
> > Hunk #1 succeeded at 538 with
> fuzz 1.
> > Hunk #2 FAILED at 1720.
> > 1 out of 2 hunks FAILED --
> saving rejects to file src/cfgparse-ssl.c.rej
> > patching file src/ssl_sock.c
> > Hunk #1 FAILED at 1750.
> > Hunk #2 FAILED at 1864.
> > Hunk #3 FAILED at 1912.
> >  

Re: [PATCH 1/2] MEDIUM: ssl: Support certificate chaining for certificate generation

[Aleksandar Lazic]

Should a blank be after '%s'?

+   memprintf(err, "%sthis version of openssl cannot attach certificate chain 
for SSL certificate generation.\n",
+ err && *err ? *err : "");

On 05.07.20 14:09, Gersner wrote:

That's my fault. I was aware of the versioning but forgot to wrap in ifdef 
there.
Configuration prevents from setting those settings on unsupported versions.


On Sun, Jul 5, 2020 at 2:57 PM Илья Шипицин mailto:chipits...@gmail.com>> wrote:

https://cirrus-ci.com/task/6191727960653824

seems, openssl-1.0.0 (used in CentOS6/RHEL6) does not support those methods.

haproxy claims to support openssl starting 0.9.8, I guess openssl-0.9.8 is 
rarely tested

вс, 5 июл. 2020 г. в 16:48, Gersner mailto:gers...@gmail.com>>:

Awesome. I will run the manual tests on the variants later today.
Thanks.

On Sun, Jul 5, 2020 at 2:45 PM Илья Шипицин mailto:chipits...@gmail.com>> wrote:

if you have tested your code (I'm sure you did), maybe manual 
testing will be simple enough
you just need to rebuild haproxy against LibreSSL, BoringSSL, older 
openssl

examples how to build ssl lib and build haproxy against it might be 
taken from .travis.yml (I was about to write an article, but I'm lazy)

вс, 5 июл. 2020 г. в 16:16, Gersner mailto:gers...@gmail.com>>:

Oh, wasn't aware of that.
Is there some automation to test this or should I manually 
verify this?


On Sun, Jul 5, 2020 at 2:13 PM Илья Шипицин mailto:chipits...@gmail.com>> wrote:

I recall some issues with LibreSSL and chaining trust. Like 
it was declared but never worked.
we'll see that in runtime if there are such issues

вс, 5 июл. 2020 г. в 16:06, Илья Шипицин mailto:chipits...@gmail.com>>:

nice, all ssl variants build well

https://travis-ci.com/github/chipitsine/haproxy/builds/174323866

вс, 5 июл. 2020 г. в 15:48, Gersner mailto:gers...@gmail.com>>:



On Sun, Jul 5, 2020 at 1:42 PM Илья Шипицин 
mailto:chipits...@gmail.com>> wrote:

do you have your patches on github fork ?
(I could not find your fork)

Yes. See branch 
https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra


вс, 5 июл. 2020 г. в 15:13, Gersner mailto:gers...@gmail.com>>:



On Sun, Jul 5, 2020 at 12:28 PM Илья Шипицин 
mailto:chipits...@gmail.com>> wrote:

does it clearly applies to current 
master ? either gmail scrambled patch or it is not.
can you try please ?

Exporting the eml and running 'git am' it 
works cleanly.

I've reproduced the exact same output when 
copy-pasting from gmail. It seems gmail converts the tabs to spaces and this 
fails the patch (Not sure why).
Running patch with '-l' will resolve this, 
but it's probably safer to run git am on the email.


$ patch -p1 < 1.patch
patching file doc/configuration.txt
patching file 
include/haproxy/listener-t.h
Hunk #1 FAILED at 163.
1 out of 1 hunk FAILED -- saving 
rejects to file include/haproxy/listener-t.h.rej
patching file src/cfgparse-ssl.c
Hunk #1 succeeded at 538 with fuzz 1.
Hunk #2 FAILED at 1720.
1 out of 2 hunks FAILED -- saving 
rejects to file src/cfgparse-ssl.c.rej
patching file src/ssl_sock.c
Hunk #1 FAILED at 1750.
Hunk #2 FAILED at 1864.
Hunk #3 FAILED at 1912.
Hunk #4 FAILED at 1943.
Hunk #5 FAILED at 1970.
Hunk #6 FAILED at 4823.
Hunk #7 FAILED at 4843.
7 out of 7 hunks FAILED -- saving 
rejects to file src/ssl_sock.c.rej

вс, 5 июл. 2020 г. в 11:46, mailto:gers...@gmail.com>>:

From: Shimi Gersner mailto:sgers...@microsoft.com>>

haproxy supports generating SSL 
certificates based on SNI using a provided
   

Re: [PATCH v2 0/2] Certificate Generation Enhancements

[Gersner]

The current implementation fallbacks to the default context certificate if
I recall correctly. No certificate will be generated in that case.

On Mon, Jul 6, 2020 at 3:01 PM Илья Шипицин  wrote:

> Hello, Gersner.
>
> smal question. what will happen if client does not provide SNI (and we are
> supposed to create certificate)?
>
> пн, 6 июл. 2020 г. в 05:12, :
>
>> From: Shimi Gersner 
>>
>> Hi Team, Ilya,
>>
>> Following the conversation yesterday I have added a fix and manually
>> tested the following openssl variants
>>   - openssl-{1.0.1e,1.0.2u,1.1.1g}
>>   - libressl-{2.9.2,3.1.1}
>>
>> Additionally I have re-ran travis/cirrus
>>   - https://travis-ci.com/github/gersner/haproxy/builds/174353855
>>   - https://cirrus-ci.com/build/5482853758664704
>>
>>
>> PR Reference
>> https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra
>>
>> Thanks,
>> Shimi.
>>
>>
>> Shimi Gersner (2):
>>   MEDIUM: ssl: Support certificate chaining for certificate generation
>>   SMALL: ssl: Support SAN extension for certificate generation
>>
>>  doc/configuration.txt|  16 
>>  include/haproxy/listener-t.h |   5 +-
>>  src/cfgparse-ssl.c   |  29 +++
>>  src/ssl_sock.c   | 153 +--
>>  4 files changed, 158 insertions(+), 45 deletions(-)
>>
>> --
>> 2.27.0
>>
>>

Re: [PATCH] ongoing typo fixes

[Christopher Faulet]

Le 05/07/2020 à 13:40, Илья Шипицин a écrit :

Hello,

I attached yet another typo fixing patch.



Now applied, thanks !

--
Christopher Faulet

Re: [PATCH v2 0/2] Certificate Generation Enhancements

[Илья Шипицин]

Hello, Gersner.

smal question. what will happen if client does not provide SNI (and we are
supposed to create certificate)?

пн, 6 июл. 2020 г. в 05:12, :

> From: Shimi Gersner 
>
> Hi Team, Ilya,
>
> Following the conversation yesterday I have added a fix and manually
> tested the following openssl variants
>   - openssl-{1.0.1e,1.0.2u,1.1.1g}
>   - libressl-{2.9.2,3.1.1}
>
> Additionally I have re-ran travis/cirrus
>   - https://travis-ci.com/github/gersner/haproxy/builds/174353855
>   - https://cirrus-ci.com/build/5482853758664704
>
>
> PR Reference
> https://github.com/Azure/haproxy/tree/wip/sgersner/ca-sign-extra
>
> Thanks,
> Shimi.
>
>
> Shimi Gersner (2):
>   MEDIUM: ssl: Support certificate chaining for certificate generation
>   SMALL: ssl: Support SAN extension for certificate generation
>
>  doc/configuration.txt|  16 
>  include/haproxy/listener-t.h |   5 +-
>  src/cfgparse-ssl.c   |  29 +++
>  src/ssl_sock.c   | 153 +--
>  4 files changed, 158 insertions(+), 45 deletions(-)
>
> --
> 2.27.0
>
>

Re: HTTP/2 in 2.1.x behaves different than in 2.0.x

[Christian Ruppert]

Hi Jerome, Willy,

thanks! Yeah, it only affected url, not path. I've fixed all cases were 
we wrongly assumed that url is like path.

Thanks for clarifying!

On 2020-07-03 19:59, Willy Tarreau wrote:

On Fri, Jul 03, 2020 at 02:25:33PM +0200, Jerome Magnin wrote:

Hi Christian,

On Fri, Jul 03, 2020 at 11:02:48AM +0200, Christian Ruppert wrote:
> Hi List,
>
> we've just noticed and confirmed some strange change in behavior, depending
> on whether the request is made with HTTP 1.x or 2.x.
> [...]
> That also affects ACLs like url*/path* and probably others.
> I don't think that is intended, isn't it?
> That looks like a regression to me. If that is a bug/regression, than it
> might be good if it's possible to catch that one via test case (regtest).
>

This change is intentional and not a regression, it was introduced by
this commit:
http://git.haproxy.org/?p=haproxy.git;a=commit;h=30ee1efe676e8264af16bab833c621d60a72a4d7


Yep, it's the only way not to break end-to-end transmission, which is
even harder when H1 is used first and H2 behind.

Also please note that "path" is *not* broken because it's already taken
from the right place. "url" will see changes when comparing with the
previous version which would see a path in H2, or either a path or a 
uri
in H1. Because if you're using "url", in H1 you can already have the 
two

forms.

Now what haproxy does is to preserve each URL component intact. If you
change the scheme it only changes it. If you call "set-path" it will 
only
change the path, if you use "replace-uri" it will replace the whole 
uri.


I'd say that HTTP/2 with the :authority header was made very 
browser-centric
and went back to the origins of the URIs. It's certain that for all of 
us
working more on the server side it looks unusual but for those on the 
client
side it's more natural. Regardless, what it does was already supported 
by

HTTP/1 agents and even used to communicate with proxies, so it's not a
fundamental breakage, it just emphasizes something that people were not
often thinking about.

Hoping this helps,
Willy


--
Regards,
Christian Ruppert