Am 13-02-2017 23:10, schrieb Willy Tarreau:
On Mon, Feb 13, 2017 at 10:50:36PM +0100, Aleksandar Lazic wrote:
What I mean is that.

haproxy have already a config parser.

Why not use this config parser and add new keyword for error files.

With this approach the customers can reuse there config without problems.

But I don't see the relation, the config parser is a line-based parser
and here the need is to be able to process text blocks possibly
containing binary contents by the way (some people distribute images,
the most common I've seen was favicons).

Oh yes you are right, as mostly ;-)

Just add new keywords like

errorfile <code> [ <file> | header <file> body <file> | template <file> ]

Wired idea ;-)

But the config parser is not a template system.

Not yet ;-)

I don't know if this keyword is also usable in lua?

How about to have the option for something like this

errorfile <code> [ <file> | header <file> body <file> | template <file> |
lua <script-file_or_URL> ]

script-file_or_URL: a location of a lua file which generates the errorfile.

That could be an approach, but the lua should probably be a function
name instead.

Yes could be.

What I assume is that some customers may want some company/app specific
error files, because it *looks* better.
With the template and/or lua file the customer can create some fancy error
pages.

Oh I'm pretty fine with this, but as a first step we need at least to be
able to continue to use what we have with header and body split apart,
and later allow to load templates and/or lua code. One difficulty with
templates is that there are approximately as many templating systems
as there are ((admins + developers) | devops). And this templating
system must allow to reference some sample expressions (and not just
variables).

That's why such a system is really difficult to build.

I know that's not a easy task.

Yep, that's why the lazy guy in me tells me we must at least make
401/407 work like others so that we can insert headers in the middle,
then allow to load a body only with a content-type. This will already
improve the current situation a lot. And we'll see some people writing
dummy servers by building backends with a 503 pointing to a different
file each :-)

I full agree with you.

Cheers
aleks

Willy

Reply via email to