On Sun, May 05, 2019 at 09:40:02AM +0200, Willy Tarreau wrote: > With this said, after studying the code a little bit more, I'm seeing a > potential case where if we'd have a trailers entry in the HTX buffer but > no end of message, we could loop forever there not consuming this block. > I have no idea if this is possible in an HTX message, I'll ask Christopher > tomorrow. In any case we need to address this one way or another, possibly > reporting an error instead if required. Thus I'm postponing 1.9.8 for > tomorrow.
So the case is indeed possible and at the moment all we can do is try to minimize the probability to produce it :-( The issue is caused by the moment we've received the end of trailsers but not the end of the mesage. >From the H2 protocol perspective if we've sent the END_STREAM flag, the stream is closed, and a closed stream gets detached and cannot receive new traffic, so at best we'll occasionally close too early and report client failures at the upper layers while everything went OK. We cannot send trailers without the END_STREAM flag since no frame may follow. Abusing CONTINUATION is out of question here as this would require to completely freeze the whole connection (including control frames) for the time it takes to get this final EOM block. I thought about simply reporting an error when we're in this situation between trailers and EOM but it will mean that occasionally some chunked responses of sizes close to 16N kB with trailers may err out, which is not acceptable either. For 2.0 we approximately see what needs to be modified to address this situation, but that will not be trivial and not backportable. For 1.9 I'm still trying to figure what the "best" solution is. I may finally end up marking the stream as closed as soon as we see the trailers pushed down. I'm just unsure right now about all the possible consequences and need to study the edge cases. Also I fear that this will be something hard to unroll later, so I'm still studying. Willy
