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]
...
####
The old format is passed without modification.
For this reason what I'm thinking about is that we'll need to keep the
headers and the body separately. And since we want to have the ability
to emit a header for certain responses (401, 407), the proper way to do
it would be to store :
- the header part from the status line to the last header, without
the
empty line ;
- the body
The function in charge of sending the response would simply have to
send :
- the header block ;
- the empty line ;
- and the body.
The function which needs to emit the 401/407 would additionally emit
the
www-authenticate or proxy-authenticate header after the header block.
If we're capable of doing this, as a first step we simply want to parse
the current errorfiles while reading them and to split them between
header and body. This way without even adding any option to the
errorfile
directive, it will be possible to pass your own errorfile 401/407 and
have it properly split then reassembled with the header field inserted.
Then as a second step we can improve it to take the content-type and
contents as in the example above, and to build the header on the fly
while parsing the file. As you can see, once the first step is realized
above, it's easy to implement the second one :-)
I'm sure there will be a request to add some variables to the
'templates'.
Do you think it's worth to build a 'simple' template language or reuse
an already available one.
BR
aleks
Cheers,
Willy