On 27.09.23 18:59, Eric Blake wrote:
We could also try to be a bit more complicated by peeking at the
next
few bytes: if they look like a magic number of the next request,
assume the client set the bit accidentally but didn't send a payload
after all; for anything else, assume the client did pass a payload.
But adding in machinery to peek at a prefix is more complex than
either assuming a payload is always present (as done in this patch) or
assuming the bit was in error (and dropping the connection
unconditionally). Preferences?
Ohh, you are right, thanks for comprehensive explanation. I really missed some things you
are saying about. Yes, now I agree that "payload always exist when flag is set"
is the best effort. Finally, that was our aim of the protocol design: make it more context
independent. Probably, we may fix that in specification as preferable or at least possible
server behavior about non-compliant client.
r-b coming soon, I just need to take another look with corrected picture in mind.
--
Best regards,
Vladimir