> I have no idea why the payload is variable-sized
For DTLS path MTU discovery (according to the heartbeat extension RFC).
Re:Xkcd: Heartbleed Explanation
by EvanAnderson on Friday April 11, 2014 @11:36AM
(#7573496)
That could have been accomplished with a fixed-length payload and variable-length padding, though.
I'm probably missing something, but if it's going to be of variable size, why not just a null-terminated string? Why does the size itself need to be specified along with the string?
EDIT: Nevermind, this thread [0] has more discussion about it.
> I would guess the specifier didn't want to bake in assumptions about how much space a unique identifier would need.
Yep, although an up-to-64KB buffer seems like overkill you'd get a guy getting by on a byte, while the other one has a distributed system and wants UUID or something
Makes sense. But 64k of data seems oddly large just to ID a message.
64k is the max value of a 2-byte unsigned int, as 2^16 - 1 = 65535; is that the size of the length prefix?
Re:Xkcd: Heartbleed Explanation
by stackcollision on Friday April 11, 2014 @03:49PM
(#7575162)
I looked at the code and I'm pretty sure I saw that the payload size variable was a long int, so I was confused by this too.
Allowing the request and response to carry a payload lets you mark each request with a unique identifier, so that you can recognise the resulting responses.
It's basically like an HTTP cookie. In reverse.
I have no idea why the payload is variable-sized, rather than being (say) a fixed 32 bits. I would guess the specifier didn't want to bake in assumptions about how much space a unique identifier would need.