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
A body is needed, but it can be empty. See HTTPbis Part 1, Section 3.3.
It's not needed. The RFC2616 however doesn't forbid it as well. Note that it does forbid the message body for certain statuses, such as 204 and 304. 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.
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.