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.
begin:vcard
fn:Ben Hollingsworth
n:Hollingsworth;Ben
org:BryanLGH Health System;Information Technology
adr:;;1600 S. 48th St.;Lincoln;NE;68506;USA
email;internet:ben.hollingsworth@xxxxxxxxxxxx
title:Systems Programmer
tel;work:402-481-8582
tel;fax:402-481-8354
tel;cell:402-432-5334
url:http://www.bryanlgh.org
version:2.1
end:vcard
