Wt

With github wt 4.0.5-31-ga05a7c5d, applications with websockets enabled (with or without the default per-message compression) can encounter corrupt request contents for clients that send multi-fragment ws13 messages. In particular, this issue has been observed with Chromium 72 and a test application that generates a large client request (170K+).

The issue appears to affect non-final message fragments (frames) when additional data is available at the time parseWebSocketMessage is called. In that case, the last buffer of payload in the non-final frame is not processed, resulting in corruption of the queryString as seen by CgiParser. The corruption is more obvious when compression is enabled.

To drive the issue for testing:

1. Use the test program and configuration instructions on issue #7034.

1. Apply the patch attached to #7034 (otherwise that issue will mask this one).
   
2. Invoke gdb, similar to following:

gdb ---args ./test_program.wt ---max-memory-request-size=512000 ---http-address=0.0.0.0 ---http-port=8080 -c wt_config.xml ---docroot=. ---deploy-path=/test ---gdb

start
b RequestParser.C:717 if state != Request::Complete
command 2
p end-begin
p dataEnd-dataBegin
end
run

Visit http://localhost:8080 with Chromium 72 browser

gdb should stop at breakpoint 2, the first value (end-begin) should be 0. Enter "c" to continue and the page should display as expected with all tableviews on row 400.

To drive the failure, add a breakpoint so that more input will be available at the call to parseWebSocketMessage:

ctrl-c to enter gdb
b Connection.C:455
run

The browser should refresh. Type "c" to continue each time gdb pauses at Connection.C:455 (less than 10 times, typically)

When gdb stops at RequestParser.C:717 (breakpoint 2), it should display two numbers. The first value (end-begin) should be non-zero. This indicates that the problem case has been hit. The second number (dataEnd-dataBegin) is the number of bytes of compressed data that will not get processed. Type "c" to continue and the browser should fail to display the expected output. Enabling debug output, the corruption should be visible in queryString (can also compare against frames captured with network tab in chromium developer tools).

Two patch files are attached:

0002-Process-last-payload-fragment-in-ws13-continuation.patch attempts to address this issue and is meant to be applied on top of 0001-Log-better-info-on-websocket-connect-fail-and-kill.patch from issue #7034. It contains block comments with additional information. The patch has only been lightly tested --- with this test application --- so it would benefit from additional review and testing.

0003-Optional-debugging-code.patch contains some optional debugging code that I found helpful while tracking this issue. It is probably too verbose for other purposes.

If I can provide further information, or if you have trouble reproducing the issue, please let me know.