Am 13-02-2017 14:47, schrieb Willy Tarreau:
Hi Aleks,
On Mon, Feb 13, 2017 at 01:19:54PM +0100, Aleksandar Lazic wrote:
Hi.
Am 13-02-2017 12:15, schrieb Willy Tarreau:
> On Mon, Feb 13, 2017 at 11:33:53AM +0100, Michael Hamburger wrote:
> > > Willy wrote:
[snipp]
> > > 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 :)
>
> OK so the first thing is to keep the compatiblity with existing
> errorfiles
> because we don't want all users to have to rewrite theirs *as long as
> they
> are valid*.
How about to reuse the config parser?
For example a errorfile could look like.
new: errorfile_301
###
[header]
Location: http://...
[body]
...
####
I must say I'm not sure I understood your proposal here :-)
(...)
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.
Just add new keywords like
errorfile <code> [ <file> | header <file> body <file> | template <file>
]
Wired idea ;-)
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.
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.
I know that's not a easy task.
Jm2c.
I'm sure there will be a request to add some variables to the
'templates'.
Definitely, I gave a few examples of this recently, such as having
req.hdr(host) reported in the contents.
Do you think it's worth to build a 'simple' template language or reuse
an
already available one.
I'd rather *not* implement a template language first until we know
exactly
what we need. And choosing an existing one before being sure about what
we
need is even worse!
Agree.
Cheers,
Willy
