RFC 2616 doesn't specify whether a message-body is needed or not, which I interpret as being optional. Is there any practical danger in omitting a message body?
For example, are there bugs (or features) in certain browsers that are triggered by a blank message body in a 302?
It's not needed. The RFC9110 spec on 302 however doesn't forbid it as well.
The server's response content usually contains a short hypertext note with a hyperlink to the different URI(s).
Note that it does forbid the message body for certain statuses, such as 204 and 304.
A [204|304] response is terminated by the end of the header section; it cannot contain content or trailers.
If the same were true for 302, then it should surely have been explicitly mentioned.
As far as I know, all modern browsers ignore the message body of a 302 in response to a GET or POST and will directly go to the URL as specified in Location header.
A body is needed, but it can be empty. See HTTPbis Part 1, Section 3.3.
AFAICT the spec describes at least two rules:
HEAD requests require the response to contain a location header. HEAD responses should never contain anything in the response body.
GET requests require that at least a hyperlink with a description be included in the response body.
Is your plan only to populate the location header?
As to your question with respect to knowing of any practical danger of responding to a GET request with an empty body, the only problem I can forsee is a functional one, when users turn auto-redirect off. Robots will also likely expect a hyperlink. As @BalusC mentioned you may have an alternative in 204 No Content response. If say the user is changing things in your app in an ajaxy way, the client code could maintain the document and entity state and the server could respond with 204's. However now I am jumping ahead and assume I know something about your use case.
