I think I've found a defect where if an http packet is > 1024 (as defined by the content-length header) packetbeat doesn't populate the http.request.body attribute. I'm testing this with curl so it could be a way curl is constructing the payload (but I doubt it).
I've tested this with both the beats input codec and logstash as well direct in to elastic search. With both approaches where the Content-Length: < 1024 it's fine, > 1024 the attribute simply isn't populated.
Tested on latest stack.
Update: Turns out this is an error with CURL. Working with a different injection tool.