Re: Fwd: Set environment variables

[Willy Tarreau]

On Mon, May 09, 2022 at 10:14:09AM +0200, Valerio Pachera wrote:
> Thank you very much willy for your reply.
> Unfortunately I'm not a developer so it will take too much time form me to
> contribute to the code.

No problem, do not worry. I've added an issue for this one:

   https://github.com/haproxy/haproxy/issues/1692

Thanks!
Willy

Re: 2.5: Possibility to upgrade http/1.0 clients to http/1.1?

[Willy Tarreau]

On Wed, May 11, 2022 at 08:43:38AM +, Froehlich, Dominik wrote:
> Hi Willy,
> 
> Thanks for the fruitful discussion!
> 
> I've opened https://github.com/haproxy/haproxy/issues/1691 to track this 
> feature request.

Thanks for this, Dominik!

Willy

Re: Patch for GitHub Issue 1530

[Willy Tarreau]

Hi Vignesh,

On Mon, May 09, 2022 at 05:38:44PM +, Vig Nesh wrote:
> Hello Team Haproxy,
> 
> Thanks for providing an opportunity to work with the product, I have
> submitted a patch for issue 1530
>  along with this email.

Now applied, thank you!
Willy

Re: 2.5: Possibility to upgrade http/1.0 clients to http/1.1?

[Froehlich, Dominik]

Hi Willy,

Thanks for the fruitful discussion!

I’ve opened https://github.com/haproxy/haproxy/issues/1691 to track this 
feature request.

Best Regards,
Dominik

From: Willy Tarreau 
Date: Monday, 9. May 2022 at 10:59
To: Froehlich, Dominik 
Cc: haproxy@formilux.org 
Subject: Re: 2.5: Possibility to upgrade http/1.0 clients to http/1.1?
Hi Dominik,

On Mon, May 09, 2022 at 08:46:20AM +, Froehlich, Dominik wrote:
> Hi Willy,
>
> Thanks for your response.
>
> Yes, I agree an option that can be turned on would be the most feasible
> solution for us.
>
> I can think of a similar option like we have for "option
> h1-case-adjust-bogus-server"
> that allows you to tell HAProxy whether to touch header casing or not.

Yes I think it would make sense because overall when you know you have
to relax this, it's more based on the LB's location than on a specific
frontend or backend, so it could just be a global option.

> Could be called "option h1-reject-get-head-delete-with-payload-bogus-client" 
> or something.

Note, we want to leave it disabled by default so that only those with
this unusual requirement would have to set the option, so the option's
name should translate that it has to accept the requests instead, so it
could be something like "h1-no-method-restriction-for-payload" or
"h1-accept-payload-with-any-method", or something like this.

> As for your question how the clients ended up sending a body with such 
> requests:
>
> The API the client is using allows them to send a DELETE request with a JSON
> document that lists all the resources to be deleted.

Ah I see, that kind of makes sense. I'm wondering if Elastic Search does
not do something similar, I seem to remember some discussions around this
when we were working on tightening the rule in the spec.

> So instead of
>
> DELETE /books/1
>
> They would send
>
> DELETE /books
> {
>   "delete": [1,2,3]
> }
>
> Weird, I know but it allowed them to delete more than one resource at a time.
> (of course, this could also be put on the path, but well... that's how they
> did it back then)

It's possible that it's easier to specify complex sets. It definitely
helps anticipate possible trouble to be expected at some places. Thanks
for the explanation!

Willy