Re: Option to reject invalid percent encoded URLs?

On Fri, Feb 25, 2022 at 11:57 AM Tim Düsterhus wrote: > As far as I can tell currently this is only possible to achieve as a > side-effect of the 'percent-*' normalizers of http-request normalize-uri: > > http-request normalize-uri percent-to-uppercase strict > > will reject requests with

Option to reject invalid percent encoded URLs?

-request seems to imply HAProxy would reject invalid URLs by default? Yours kindly, Jesse Hathaway

Re: DNS resolution problem on 1.6.1-1ppa1~trusty

On Wed, Oct 28, 2015 at 4:41 PM, Baptiste wrote: > So, when you write >if (cname && memcmp(ptr, cname, cnamelen)) >return DNS_UPD_NAME_ERROR; > else if (memcmp(ptr, dn_name, dn_name_len)) > return

Re: DNS resolution problem on 1.6.1-1ppa1~trusty

On Tue, Oct 27, 2015 at 8:18 PM, Baptiste wrote: > #2 an error in the way we parse CNAME responses, leading to return an > error when validating a CNAME (this triggers bug #1). How does your patch for this issue change the logic? It appears functionally the same to me.

Re: DNS resolution problem on 1.6.1-1ppa1~trusty

On Wed, Oct 28, 2015 at 12:00 PM, Baptiste wrote: > Good catch, forget about patch 1, It was 2AM in the morning when I > wrote it :'(... > I wanted to apply the same code as DNS_UPD_NO_IP_FOUND, and increment > the OTHER error. That is interesting, but I was asking about

SIGUSR1 soft stop does not send "Connection: close"

>From my reading of the code SIGUSR1 does not send a "Connection: close" to the client or server. This means it is not possible to safely close a keep-alive session, before terminating HAProxy. Would there be interest in a patch to send "Connection: close" on both the request and the response,

Re: SIGUSR1 soft stop does not send "Connection: close"

On Thu, Oct 15, 2015 at 2:11 PM, Lukas Tribus wrote: > When specifically would you intervene? Could you elaborate what you > have in mind? My goal is to shutdown a HAProxy daemon without interrupting any inflight requests or responses. > If the session is transferring HTTP

Re: SIGUSR1 soft stop does not send "Connection: close"

On Thu, Oct 15, 2015 at 12:26 PM, Lukas Tribus wrote: > What request/response, aren't we talking about an idle session here? No, I am concerned with a non idle persistent session.

Re: Interactive stats socket broken on master

On Sun, Oct 11, 2015 at 5:06 PM, Willy Tarreau wrote: > > Has anyone else tested it ? Since the beginning of the thread I must > confess it's unclear to me as Jesse reported the issue, you said that > your patch works for you then Jesse asks whether we should merge it. > Jesse, have

Re: Interactive stats socket broken on master

On Fri, Oct 2, 2015 at 10:24 AM, Andrew Hayworth wrote:> > Attached is a patch that fixes the issue for me. Willy, any thoughts on merging this patch into 1.6?

Interactive stats socket broken on master

It appears the following commit broke the interactive stats socket. When this commit is applied the stats socket disconnects after typing prompt and hitting enter. This breaks applications such as hatop. We found the breaking commit using git bisect. Please let me know if I can help debug

Re: segfault with 1.6 10ec214f41385b231a0c4c529b7b555caf5280bb

Cyril Bonté writes: > In some conditions, srv_conn is set to NULL but is then used later. Awesome, I will roll out a new version based on master today, thanks Cyril!

segfault with 1.6 @10ec214f41385b231a0c4c529b7b555caf5280bb

I received the same segfault on two different hosts with the following sanitized config. I am not sure how to debug further at this point, any advice would be appreciated. resolvers bar nameserver dns1 192.168.1.1:53 nameserver dns2 192.168.1.1:53 resolve_retries 3 timeout retry 1s

Re: [PATCH] Compress HTTP responses with status codes 201,202,203 in addition to 200

On Wed, Mar 11, 2015 at 5:25 PM, Willy Tarreau w...@1wt.eu wrote: Your mailer has wrapped long lines. You'll have to configure it to prevent it from doing so. This time I could fix it, it wasn't difficult. I will do that in the future, thanks for munging it for me this time.

[PATCH] Compress HTTP responses with status codes 201,202,203 in addition to 200

It is common for rest applications to return status codes other than 200, so compress the other common 200 level responses which might contain content. --- src/proto_http.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/proto_http.c b/src/proto_http.c index

unique-id-format

In the documenation it states: The format should be composed from elements that are guaranteed to be unique when combined together. Is there a combination of formatting strings that would guarantee uniqueness? Would a patch to add a uuid formatter be accepted? Thanks, Jesse

stick-table counters and multiple HAProxy instances

Our current HAProxy configuration relies on acls of the form: acl few_concurrent_requests sc0_conn_cur(http-in) le 5 acl few_avg_connections sc0_conn_rate(http-in) le 5 We use these to analyze the connection rate and concurrent requests of our customers. We would prefer to have multiple

Compression for response codes other than 200s such as 201s?

According to the configuration manual: Compression is disabled when: * HTTP status code is not 200 However, many APIs return a 201 response from a post request. What is the rationale for only enabling compression on 200 response codes? Thanks, Jesse

Compression for response codes other than 200s such as 201s?

The HAProxy configuration manual contains the following note: Compression is disabled when: * HTTP status code is not 200 However, many rest APIs send back a 201 status code after receiving a POST. What is the rationale for only compressing responses with a 200 status code? Thanks, Jesse

Compression for response codes other than 200s such as 201s?

The HAProxy configuration manual contains the following note: Compression is disabled when: * HTTP status code is not 200 However, many rest APIs send back a 201 status code after receiving a POST. What is the rationale for only compressing responses with a 200 status code? Thanks, Jesse

Support for fair share concurrent request scheduling?

Does haproxy have support for fair share concurrent request scheduling? Description: Give each user at least their fair share of concurrent connections based on the current number of users and if capacity exceeds that allotment fairly share the excess capacity among those users that have