> But you said that #2 solution was more RFC compliant... 
> Could you please quote the RFC part that describes this behaviour?

RFD2616
http://www.faqs.org/rfcs/rfc2616.html

section 4.3 Message Body ...

   The presence of a message-body in a request is signaled by the
   inclusion of a Content-Length or Transfer-Encoding header field in
   the request's message-headers. A message-body MUST NOT be included in
   a request if the specification of the request method (section 5.1.1)
   does not allow sending an entity-body in requests.

[I couldn't actually find a quote saying that GET has no body, but ... it 
doesn't.]

Section 10.3 Redirection 3xx says 

   The action
   required MAY be carried out by the user agent without interaction
   with the user if and only if the method used in the second request is
   GET or HEAD.

In other words, changing it to GET may not be quite pure, but leaving it as 
POST would technically mean that the user MUST confirm that the redirect is 
OK.  This MUST NOT becomes more explicit later, such as in 10.3.2 (301 Moved 
Permanently).  Section 10.3.3 (302 Found) says that 307 was added 
specifically to insist on keeping it a POST, and even 307 says it MUST NOT 
automatically redirect unless it can be confirmed by the user.

Which is why user agents change redirects to a GET and try that...