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 _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
