Hi Dominik,
On Mon, May 09, 2022 at 08:46:20AM +0000, 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<http://docs.haproxy.org/2.5/configuration.html#4.2-option%20h1-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
