-
Notifications
You must be signed in to change notification settings - Fork 165
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
Rapidoid crashes when processing requests that use Transfer-Encoding. #183
Comments
After returning to have another go at this issue, I've been able to stop the issue if I just send all of the data at once. This means that there's actually two more things that could be doing something.
|
After poking it more, I'm about 99% sure it doesn't come from my InputStream code. This leaves Java or Rapidoid. |
Having poked it a lot more, I think I've determined the issue. So, I guess after all of that, I should probably change this ticket to support Requests that use that. |
So, yeah, I think the biggest thing right now is the fact I can bring down any rapidoid server just by sending a request that uses this... |
@Jezza Thanks a lot for the detailed investigation and for reporting this! This looks like a serious problem, indeed. I managed to simulate the problem by throwing the exception intentionally, and I received the same error trace. However, I didn't manage to crash the server. The response ordering is done independently for each connection, so in theory receiving one problematic request from one client connection shouldn't affect the other clients / connections, unless I am missing something. Can you please confirm that after receiving such request, the server cannot process any other regular requests from the other connections? If that is the case, it would mean that I didn't manage to reproduce the exact problem. I would really appreciate if you can send me the exact HTTP request - preferably by email at |
Heyo, thanks for the speedy response. |
Thanks again for helping with the investigation and for providing all the details! I managed to reproduce the exceptions with the program that you provided. However, the server doesn't crash, the exceptions are just being logged. Additionally, I wrote a test that sends the same request (in a bit different way, though), but the effect is the same - the same exceptions occur, but the server doesn't crash. So far I didn't manage to find a scenario where the server/worker would actually crash. Can you please check if a worker will actually crash after processing your request? I propose the following test:
Thanks! |
No problem! Hm, that's really weird. Either way, I'm glad it's reproducible. |
(cherry picked from commit 70b6eed)
Ok, so after an hour or two of smashing my face against this problem, it's a bit of a doozy...
I've written a shitty http client that can send Multipart POST requests to a server.
The server I was using to test against was Rapidoid, as it's insanely easy to do anything. (Props for that).
The library I'm writing uses the new Java 11 HttpClient, and as far as I can tell, the problem doesn't lie with that.
The problem:
An attempt to describe said problem:
After poking it for a bit, I've determined that the
HttpManagedHandlerDecorator
promotes the connection to async, when it shouldn't.But it does so in an alternating fashion.
So, I chunk up the request, because, well, that's a good thing to do.
When the first chunk comes through, rapidoid processes it without issue.
As it was processing the first chunk, the connection seems to be set to
sync
, and it tells the connectionthat the seq 0 was handled.
The problem arises when the next seq is handled.
For some reason,
HttpManagedHandlerDecorator
sets it to async:So the connection is now marked as async, and the RapidoidWorker checks if the current request is async, if so, it doesn't care, and continues processing.
Meanwhile, it sets it back to sync, so when the second chunk comes in, the connection errors out, because
it was marked as sync, and as a result, tries to tell the connection that seq 2 was handled, but the
connection was never informed about seq 1, so it throws the error.
Beyond that, I have no idea.
If this wall of text helps in some way, awesome.
Otherwise I'm fine answering any questions you might have.
The client I've written isn't public yet, but I'd be happy to give you the code to take a look.
The text was updated successfully, but these errors were encountered: