Am 19-04-2017 11:24, schrieb Thierry Fournier:
On 19 Apr 2017, at 09:16, Aleksandar Lazic <al-hapr...@none.at> wrote:
Am 19-04-2017 05:51, schrieb Willy Tarreau:
On Tue, Apr 18, 2017 at 11:55:46PM +0200, Aleksandar Lazic wrote:
Why not reuse the upcoming http/2 format.
HTTP/2 is *easy* to parse and the implementations of servers are
growing?
Are you kidding ? I mean you want everyone to have to implement HPACK
etc ?
Well there are a currently lot of http/2 servers out there, but I
understand your concerns.
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?
Code generators are always a pain to deal with. It reminds me the old
days
when I was using rpcgen. And grpc doesn't provide a C implementation
so that
kills it :-)
Yeah I have also seen that they prefer c++, c#, go and other languages
but not offer a c lib.
This is strange just because the core is written in c, but I don't
need to understand everything ;-)
Thierry told me he's going to implement a simple TLV-like list which
will
be much easier to implement and easy to code on both sides.
@Thierry:
Ah something like netstrings ?
https://cr.yp.to/proto/netstrings.txt
Hi thanks for the link. I do not like this encoding because it is not
easy to
parse. I must read ascii representation of numbers and convert-it. I
prefer
simple binary format, with length (encoding in the same way than the
SPOE
protocol) and value.
Thanks for clarification.
Hi, the main goal is providing:
- a format easy to decode
- not adding lot of dependencies to haproxy
That's very polite.
So, after brainstorm, I propose:
- remove all data already accessible via existing sample-fetches from
the new
sample-fetch introduced by my previous patch. These data are:
method, path, query string, http-version and the body. All of these
data are
available in some sample fetches and it will be great to reuse it.
Note that
the only data which keep are the headers.
- For the headers I propose two format: The first format is for
general use. It
is simply the header block in the same format that we received
(with the final
\r\n for detecting truncated header bloc)
- For header I propose also a binary format like this:
<number of headers>
[
<header name length><header name content>
<header value length><header value content>
]…
This format is easy to decode because each length is encoded with
the SPOE
numeric values encoding method, so it is always embedded in SPOE
client.
The SPOE message description will become
spoe-message check-request
uniqueid args method path query req.ver req.hdrs_bin
req.body_size req.body
uniqueid is a string which allow to do matching between the mod
security logs and
the haproxy logs. I propose the uniqueid, but this string can
be another
think like an header containing a uniqueid previously
generated.
req.hrds_bin is the header bloc in binary format.
req.body_size is the advertised size of the body and it is used to
determine if the
body is full or truncated.
Looks good to me.
Regards
Aleks
Thierry
I personally
think that adding dependencies on tons of libs to implement simple
stuff
is more of a problem than an help even for implementors, because when
you
start to enter some dependency hell or version incompatibilities,
it's a
real pain, especially when it was done only to find how to implement
just a small list. These things are useful if you want to implement
heavy
inter-application communications but it's not really the case here.
I got you.
Cheers,
Willy
Regards
Aleks
