Re: [squid-users] Redirects changing POST to GET

>> The problem I'm seeing is that whenever a CGI is called via HTTP with a
>> POST method, it gets converted to GET when the new request comes in on
>> HTTPS. This, of course, breaks the app.
>> I should mention that we've experienced this with both IE 7 on WinXP and
>> with Firefox on Ubuntu Linux.
>>
>> I did some packet dumps during the switchover. Here's the proxy's reply containing the 301 redirect to the HTTPS
>> version of the same URL. Content-Length is zero (is that bad at this
>> point?), and no method is specified.
>
> <snip>
>
> The critical point being that it was the browser that initiated the GET
> information. Last squid saw was a POST.
>
> I've done a bit more research and found the RFC2616 section relevant to
> this. It's seems that this is a standards violation being committed by the
> redirector (NOT a good idea to reply 301/302 to a POST request.) and the
> consequences are being felt.

For the benefit of those reading this in the archives later on, I found this in section 10.3.2 (the 301 return code) of RFC 2616:
http://www.ietf.org/rfc/rfc2616.txt?number=2616

   If the 301 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0 user agents
      will erroneously change it into a GET request.

And then from section 10.3.4 (302 code):

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request. However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method. The status codes 303 and 307 have
      been added for servers that wish to make unambiguously clear which
      kind of reaction is expected of the client.

> I think the proper solution here would be to fix the form that is POSTing
> to the wrong URL according to your policy. You can use the "it can't be
> fixed" line (which is nearly true, the only 'fix' would be to 404 them :-(
> anyway)
>
> The exact behaviour appears to be browser-dependant with some weird
> effects occuring on some non-standard ones (Netscape and IE for starters).

This does seem to indicate that my desired approach of forcing encryption between us and the user by redirecting all HTTP requests to HTTPS won't work. Changing the method used in the scripts isn't possible, either, as this is a shrink-wrapped app. Back to the drawing board, I guess. Thanks so much for all your help, Amos.