-
-
Notifications
You must be signed in to change notification settings - Fork 356
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pull in QT WebSocket library for parsing #1338
base: master
Are you sure you want to change the base?
Conversation
bf8238b
to
c6f3d7c
Compare
@mcallegari I see—sorry, I thought I was trying something new by copying in the sources. However, I was able to get much further in just a couple hours of work, compared to #1335. I tried this because when I was running the tests on #1335 there were still more than a few failures that could plausibly cause data corruption or some other problems in the future. I can provide the test results if you're interested. Maybe you can still take a look at this, I seem to have everything working. There's just the errors from the code analysis tool that can probably be ignored. |
14a42bf
to
97ab647
Compare
e23e3a1
to
97b2860
Compare
@mcallegari There seems to be an error with the AppVeyor builds in general (was there a system change?), but otherwise it should pass, and I think this is ready for your consideration. The Codacy analysis shows one type of error ("Check buffer boundaries") which can be ignored: in all the cases the code has already checked the buffer boundary using |
This avoids crashes when frames arrive in separate TCP packets.
@mcallegari This PR is ready for your consideration, could you please take a look? The only remaining error is the code analysis wants read() calls to check the return value, which it is doing. |
As I mentioned here a month ago, I'm not sure if I want to drag in another Qt dependency to the project. |
@mcallegari I'm hoping to submit a number of other improvements to the Web interface, especially around tempo, and even with the simple fixes that prevents crashing, the test suite still flagged a number of other issues that will likely cause problems, see qlc+-websocket-parsing.pdf. We could write code that fixes all of those problems, but it would not be as quick to implement, or easy to maintain, as copying in an existing parser. No dependencies have been added, it uses the same public Qt API that the rest of QLC+ uses. I spent several days on #1335; I was able to finish this PR in a couple hours. In my testing, everyone who uses Wi-Fi is affected. |
@mcallegari Can you please merge this? It doesn't add any dependencies. |
This avoids crashes when frames arrive in separate TCP packets.
This is an alternative to #1335 and closes #1308. It pulls in the official Qt parser, which is otherwise a private API.
This is the output from a websocket test suite, index.html.pdf. The failed cases 1.1.6/1.1.7/1.1.8/1.2.6/1.2.7/1.2.8 are testing packet lengths that are too big, and the Qt code responds appropriately with response code 1009.
(To get it to work with the test suite, you have to slightly modify the code to echo back complete messages, see the following patch.)