HTTP/1 balsa parser prematurely purges parsed headers resulting in status monitor failure

[RenjieTang]

During UpstreamHttp11ConnectSocket::isValidConnectResponse(), a framer is used under the hood to parse the header. Later its statusCode() is used to determine validity.

However, when the response header contains content-length: 0, BalsaParser::MessageDone() will be invoked which purges the parsed header. Later when statusCode() is called, since the header is empty, the default 0 status code is returned and the response is mistaken as invalid.

This bug is sneaky because when content-length isn't present, the framer will wait to read more data until the connection close, and thus MessageDone() is never called.

I think the correct fix should be to not reset the header when the framer is cleared, because the header is owned by the BalsaParser.

[RyanTheOptimist]

@bencebeky

[alyssawilk]

Also, looks to me like onStatus is returning the reason phrase, not the status code? rename or fix is in order?

[bencebeky]

Also, looks to me like onStatus is returning the reason phrase, not the status code? rename or fix is in order?

That is correct. This is pre-existing from before BalsaParser was added. What makes most sense to me is to lump fixing this with other cleanup tasks in the far future when http-parser gets removed.

[bencebeky]

During UpstreamHttp11ConnectSocket::isValidConnectResponse(), a framer is used under the hood to parse the header. Later its statusCode() is used to determine validity.

However, when the response header contains content-length: 0, BalsaParser::MessageDone() will be invoked which purges the parsed header. Later when statusCode() is called, since the header is empty, the default 0 status code is returned and the response is mistaken as invalid.

This bug is sneaky because when content-length isn't present, the framer will wait to read more data until the connection close, and thus MessageDone() is never called.

I think the correct fix should be to not reset the header when the framer is cleared, because the header is owned by the BalsaParser.

Thank you for raising this issue.

I don't think the right approach is to not reset BalsaHeaders along with BalsaFrame. BalsaParser is designed to parse multiple messages, so it makes sense to reset BalsaHeaders and BalsaFrame at the same time. I propose saving the value of the status code when the headers are parsed, and keeping it either until the first byte of the next message is parsed, or as long as possible, until the headers of the next message are parsed.

Another approach would be not to reset BalsaFrame and BalsaHeaders when parsing the message is complete. I think as long as we only need access to a single integer, it is better to reset them early, because they take up memory, but this would also be a viable approach if more state would need to be accessed.

[alyssawilk]

is it just the single integer? looks like isHttp11 also refers to headers, as does contentLength and possibly others (I stopped at n=2). I think it'd be safer to keep headers around rather than trying to latch all of the fields and hope we don't forget to do so in future.

[bencebeky]

is it just the single integer? looks like isHttp11 also refers to headers, as does contentLength and possibly others (I stopped at n=2). I think it'd be safer to keep headers around rather than trying to latch all of the fields and hope we don't forget to do so in future.

Oh thanks, that's a very good point.