Without "http-request set-header host" and "http-request replace-path",
balance algorithm works the same for both http/1.1 and http/2.
2020년 9월 21일 (월) 오후 4:55, Sehoon Kim 님이 작성:
> In 2.2.3, http/2 and http/1.1 request seems to select different servers.
> But in 2.0.17, http/2 and http/1.1
Hi,
if I try to connect to a spoa server with haproxy 2.2.3 and nbthread
greater then 1, then if n is the nbthread value, only the first and
thereafter n-th requests are answered correct and requests in between
are not correctly forwarded to the spoa server. Is this a known
limitation or is this
Hello,
I'm testing this behaviour with 2.2.3-0e58a34 with the line
"http-request del-header x- -m beg" but it reports an error:
[ALERT] 264/110329 (5812) : parsing [/etc/haproxy//haproxy.cfg:91]:
'http-request del-header' expects either 'if' or 'unless' followed by a
condition but found
you can get version by REST api. here's an example in PowerShell
*$version* = Invoke-RestMethod -Method 'GET' -Uri
'http://xxx.xxx.xxx:/v1/services/haproxy/sites' -Credential $Cred
-AllowUnencryptedAuthentication
$transaction = Invoke-RestMethod -Method 'POST' -Uri
Hi,
I posted this on the discourse haproxy forum and was asked to post it
here for better visibility :
We recently switched to haproxy 2.2.2 and we encountered a problem
with the flexibility of ssl-load-extra-files.
The way we handle certs is as follows:
Public key name is : fqdn.pem
Private
In 2.2.3, http/2 and http/1.1 request seems to select different servers.
But in 2.0.17, http/2 and http/1.1 request seems to select same servers.
So, we can't use backend cache farm effectively, because of low cache hit
ratio.
2020년 9월 21일 (월) 오후 4:48, Jonathan Matthews 님이 작성:
> Perhaps you
I’ve not used the API yet, but my reading of those docs, alongside some
previous experience, suggests to me that the version should br an entirely
user-specified, opaque-to-haproxy string, whose purpose is to avoid stale
config writes from concurrent clients.
However, the fact that the version
Ricardo,
Am 21.09.20 um 11:29 schrieb Ricardo Fraile:
> One mail on this thread said
Your MUA appears to not specify the 'references' or 'in-reply-to'
headers that are required for proper threading. This makes it
unnecessarily hard to find the thread.
To prevent all the others from searching
version is required if you wish to perform complex change, "transaction" in
terms of dataplane api.
for simple change indeed it is not required.
пн, 21 сент. 2020 г. в 14:29, Jonathan Matthews :
> I’ve not used the API yet, but my reading of those docs, alongside some
> previous experience,
For example, to start a new transaction, as the documentation [1]
points:
version / required
Configuration version on which to work on
Or the blog post about it [2]:
Call the /v1/services/haproxy/transactions endpoint to create a new
transaction. This requires a version parameter in the URL,
Hi,
We are upgrading from haproxy 2.0.17 to 2.2.3.
And we use path rewriting and "balance uri whole" before sever selection.
But server selection in 2.2.3 seems to be different from 2.0.17.
-
backend bk_test
balance uri
Perhaps you could expand upon the differences you perceive, and the effect
and impact they’re having?
On Mon, 21 Sep 2020 at 07:51, Sehoon Kim wrote:
> Hi,
>
> We are upgrading from haproxy 2.0.17 to 2.2.3.
> And we use path rewriting and "balance uri whole" before sever selection.
>
> But
On Mon, Sep 21, 2020 at 11:23:06AM +0200, Marc Antoine Leclercq wrote:
> Hi,
>
> I posted this on the discourse haproxy forum and was asked to post it
> here for better visibility :
>
> We recently switched to haproxy 2.2.2 and we encountered a problem
> with the flexibility of
Hi,
the following haproxy configuration produces different results with
haproxy 2.0.16 (and 1.8.20) vs 2.2.3 running with "haproxy -f
haproxy.conf -d":
global
stats socket /tmp/haproxy.sock mode 660 user haproxy group haproxy
level admin
defaults
mode http
frontend fe-a
bind :10001
14 matches
Mail list logo
