Le 18/04/2017 à 14:40, Willy Tarreau a écrit :
On Tue, Apr 18, 2017 at 12:15:20PM +0200, Christopher Faulet wrote:
I finally took the time to review your patches, mainly the second one, about
the sample fetch. I think it would be pity to introduced such complex sample
fetch. All parts, except the HTTP headers, are already available in
dedicated sample fetches. It could be better to only add a sample fetch to
get HTTP headers (req.hdrs and res.hdrs, something like that). Because a
sample fetch cannot return a list, we can probably encode it into a binary
buffer using a \0 as separator. something like:
<num-of-headers><header-name>\0<header-value>\0<header-name>\0<header-value>\0...
This way, the sample fetch does not depend on the SPOE and can be used in
another context. And concerning your SPOA, this will be quite easy to parse
it.
Actually I'm not quite sure about this one, such an encoding could in fact
make it harder to process while most use cases will either want to log it
(thus copy the whole string as-is) or decode it as received (and might have
to rebuild the initial header block with CRLF in between).
My first idea was to avoid the headers parsing in the SPOA. Because it
was already done by HAProxy, it could be cool to not redo it. Maybe the
sample fetch can take an argument to choose the format (raw or encoded).
The format is open. \0 may not be the better separator. This is just a
trick to deal with a list, like req.hdr_names.
However I agree that having something like req.hdrs / res.hdrs could be
useful instead of having the whole block containing all the buffer. We
already have "req.body" for the body as a binary block, so it totally
makes sense to have "req.hdrs" for the same purpose, and let agents deal
with either one or the other or both.
--
Christopher Faulet
