> 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.
Hi, the main goal is providing:
- a format easy to decode
- not adding lot of dependencies to haproxy
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.
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
