> OK, after a few days on other projects, I'm back with more info on this.
>
> Amos Jeffries wrote:
>>>>> 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.
>>
>>> Has anybody seen this behavior before, or heard anything that would
>>> indicate the conversion is a security feature?
>>
>> Try squidclient -h ?? -p 80 -m POST http://...
>> and see what squid gives back in the 301 headers.
>
> It balks because I haven't specified a Content-Length. I assume this is
> merely a problem with my invocation of squidclient, and unrelated to my
> root problem of POSTs changing to GETs. How do I specify a
> Content-Length? I can't find any documentation on squidclient. (There's
> more important questions below this snippet of output.)
"squidclient --help"
(This is for squid3-client, I think 2 is the same for this)
Usage: squidclient [-arsv] [-i IMS] [-h remote host] [-l local host] [-p
port] [-m method] [-t count] [-I ping-interval] [-H 'strings'] [-T
timeout] url
Options:
...
-H 'string' Extra headers to send. Use '\n' for new lines.
...
>
> # squidclient -h revproxy.bryanlgh.org -p 80 -m POST
> http://ocsinf.bryanlgh.org/pls/orasso/orasso.wwsso_app_admin.ls_logout
> HTTP/1.0 411 Length Required
> Server: squid/2.6.STABLE6
> Date: Thu, 31 Jan 2008 22:13:08 GMT
> Content-Type: text/html
> Content-Length: 1272
> Expires: Thu, 31 Jan 2008 22:13:08 GMT
> X-Squid-Error: ERR_INVALID_REQ 0
> X-Cache: MISS from revproxy.bryanlgh.org
> X-Cache-Lookup: NONE from revproxy.bryanlgh.org:80
> Via: 1.0 revproxy.bryanlgh.org:80 (squid/2.6.STABLE6)
> Connection: close
> <snip squid err page>
>
>
> Also, I did some packet dumps during he switchover. In the following,
> "musketeers" represents the client's web browser. "revproxy" and
> "192.168.2.67" are the reverse proxy server running squid.
> "172.22.66.206" are the internal servers behind the proxy.
<snip>
>
> And 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.
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).
Meanwhile squid has a bug in that it allows the redirection of POST
requests. I've added that to bugzilla for correction as
http://www.squid-cache.org/bugs/show_bug.cgi?id=2209
Amos
