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. Willy
