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). > 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. > 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. > 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). > 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 :-) Willy
