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