On Tue, 12 Sep 2006, MARMOLLE Frank wrote:

> Last august 22th, I sent a post about problems when trying to communicate
> between a client application using cURL and a target application thru a
> proxy-firewall Cisco ASA 5520, with POST HTTPS. The http response given by
> the Cisco ASA, includes an html page wich seems not to be interpreted and
> treated correctly by cURL, which falls in error.

The html page is not interpreted at all. curl interprets HTTP only here.

> curl https://xxxxx.fr -m 3600 -s -S -i -o TMP08A4008A6.out --data-binary
> "@TMP08A4008A6.in" -u username:password -L --trace-ascii logfile.log -K
> TMP08A4008A6.curl
>
> The test failed :
> The POST seems to have been switched to GET. By what ? How to avoid it ?

By curl since the server sent back a 301 and that's what curl will do on 301
responses. While the 301 is said in RFC2616 to not be allowed to change
request to GET, browsers do it and thus so does curl.

> The html response page isn't managed by cURL (?) and the redirection didn't
> occur.

The redirect certainly did occur, your verbose output clearly says so:

> 0000: Location: https://xxxxx.fr/index.html

...

> == Info: Follows Location: to new URL: 'https://xxxxx.fr/index.html'
> == Info: Violate RFC 2616/10.3.2 and switch from POST to GET

> Have anyone done such http communications with cURL and a proxy-firewall
> (Cisco ASA) ?

Again: it doesn't matter what software that runs on the server (and even if
you use that box as a proxy, you're not communicating with it as a proxy here
but as a server). HTTP is standardized and curl speaks it fine.

I'd say you most probably send the POST to the wrong URL. Use LiveHTTPHeaders
or another way to snoop on a browser when you do it with that, and then make
sure your curl command line does the same.

Also note that curl 7.9.7 is almost 4.5 years old and is considered outdated,
deprecated and not really suitable to use.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html