Repository navigation
fix: end message on connection close - #784
Conversation
|
@Ethan-Arrowood if you agree with this would you mind helping with creating a test? |
Codecov Report
@@ Coverage Diff @@
## main #784 +/- ##
==========================================
+ Coverage 99.84% 99.87% +0.02%
==========================================
Files 25 25
Lines 1942 2335 +393
==========================================
+ Hits 1939 2332 +393
Misses 3 3
Continue to review full report at Codecov.
|
4ec4267 to
d48e7d2
Compare
If response is not keep alive and socket ends then consider it as end of message.
d48e7d2 to
004bec4
Compare
|
I actually disagree with this change myself but leaving it here for visibility and discussion. |
|
Before I can form a real opinion here I'd like to simplify and reproduce. We should try and emulate with just a node.js http server and see what happens. I'm not well versed enough in http spec to know exactly what should happen either. |
|
I think we should land this change, it's what users would expect. There is a HTTP/1.1 spec violation that we should document as there is no |
Just so we are all in agreement. There is actually (probably?) no way to tell whether we properly received the full body. So in theory the user could receive an incomplete body without error. Are we ok with that? |
|
I think there might be a trailing Also does llhttp error for responses that don't have content-length nor chunked encoding but has |
dnlup
left a comment
There was a problem hiding this comment.
Right now, I am not sure about it either. I have read the discussion, and I think this would be necessary only if lhttp doesn't call onMessageComplete in this scenario. I need to see what Node core does in this case. That might give some inspiration.
|
I remember having a different behavior with control characters in headers using |
|
I stumbled upon this as well. Can we land it? |
I'm not comfortable landing it in it's current form. Would like to see if there is any \r\n we can detect and use. |
|
I'll investigate further and try to reproduce with Node. |
|
Also would be good to have a separate test for the case where it's keep alive and whether or not that must error. |
|
another thing to consider is whether to only allow this behavior for failure status codes? |
|
Could unidici just call |
|
@ronag I pushed a test and a fix. I had to disable another test which is mutually exclusive as far as I understand. I think we should be lenient in this case. |
ronag
left a comment
There was a problem hiding this comment.
What about llhttp_finish?
I'm investigating it. |
|
Using llhtp_finish fixed most problems indeed. |
|
LGTM, apart from the comment for the keep-alive test. |
|
LGTM, will make a rc2 release? |
|
As soon as the test pass! 🎉🎉 |
If response is not keep alive and socket ends then consider it as end of message.
I'm not sure whether this is spec compliant but I believe it would resolve the issue @Ethan-Arrowood encountered.
Refs: #782