Am 18-04-2017 15:10, schrieb Willy Tarreau:
On Tue, Apr 18, 2017 at 02:59:20PM +0200, Christopher Faulet wrote:
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.
I think there are different needs. I totally agree that if we can build
a
list to avoid SPOAs having to parse headers it would be cool, but at
the
same time we need to keep in mind that some components there will
expect
to receive the request as-is and in this case having to transform it
twice
needlessly adds some complexity. So in the end I'm all for having a
req.hdrs
and res.hdrs which contain the exact block as received, just like we
have
for the body, and on top of this we can have some variants where an
easy to
use serialization and encoding is applied. Maybe we can even think
about
header factorization to avoid sending multiple times the same header
name
with different values. Just an idea.
Why not reuse the upcoming http/2 format.
HTTP/2 is *easy* to parse and the implementations of servers are
growing?
I know this is still on the todo list but I think this is worth to go
instead to add another protocol.
Or we can take a look into grpc, which is on top of http/2 with
protobuffer.
http://www.grpc.io/
As I take more time to think in this direction why not add a grpc filter
like the spoa filter?
Opinions?
I can take a look to implement it.
Willy
Regards
aleks
