Hello Willy,
thanks for answering.
Thanks for the description. However this change causes a big issue which
is that a printf-format file is directly exposed outside. The nasty side
effect is that someone using 2 "%s" instead of exactly one will cause
the process to randomly crash for example, and there's a warning about
it just before their declaration, which explains why they were not merged
with the other ones.
Weren't it easier to parse the custom errorfile and when two or more
"%s" are found terminate HAProxy and give a error message that only one
"%s" must be used.
Interestingly your proposal raises a new issue which we didn't think
about. Recently a few of us wanted to make the error pages more
configurable (typically templates in which we could use some sample
expressions, a-la log-format). But your request shows one limit to this
model that we also have to take into account.
This tends to make me think that most of the time users only need to
set the response body and will not care about the headers which will
automatically be filled by haproxy. I'm thinking that we could imagine
a new way to declare error files with more arguments :
errorfile 401 type text/html content 401.html
That would remove the need for the "%s" in the www-authenticate field
and would make it easier to later implement dynamic contents since our
headers would have to be automatically computed already.
I agree and to be honest I was surprised that this isn't the case
already. For my use-case this is totally satisfactory.
Maybe you're interested in trying to implement the stuff above ? If
so, just let me know, I can give you a few hints which could possibly
help.
I would like to help but I need to find some free time for that. If you
can spare some minutes I would love to get a few hints :)
Michael
