Hello again,

We have narrowed down the scope of the problem. If submitting a valid XML
request file to the server, curl receives response data from the server. If
submitting a valid fixed-length request file to the server, curl receives a
header response (if -I option is included) but no response data from the
server.

According to the third-party I am attempting to process with, users have
used other HTTPS Post utilities with the only requirement being that the
fixed-length data is stored in the BODY of the HTTPS message. Is there a
way to mimic this behavior? My concern is that when curl receives the
HTTP/1.1 200 OK response it does not look for the response data that is then
returned by the server.

With the XML request, I am able to suppress the HTTP/1.1 200 OK with the -X
option but this does not work with the fixed-length data.

This is the command string that works with the XML:

curl -v https://cert.xyzcompany.com:99999 --cacert "cert.txt" -k --max-time
300
 -H "User-Agent:" -H "Host:" -H "Pragma:" -H "Accept:" -H "Content-Length:"
-H "
Content-Type:" -H "Expect:" -X "<?xml version=\"1.0\"
encoding='UTF-8'?><!--" --
data-binary "@myinputdata.xml" > myreplydata.xml

The XML file starts with: --><Request version="3.0"
xmlns=http://www.xyzcompany.com/schema...

i.e., "-->" is appended to the beginning of the data to closeout the comment
"<-- HTTP/1.1 -->" that results from the curl command.

Using the -X string for the fixed-length data causes the xyzcompany to not
recognize the data format even with the "-->" prefix.

Removing the -X string and "-->" prefix from the file causes the HTTP/1.1
200 OK response to be received, xyzcompany recognizes the data format,
processes the file, and creates response data -- but the response data does
not end up in my response file "myreplydata.txt." Here is the command
string that is being used here:

curl -v https://cert.xyzcompany.com:99999 --cacert "cert.txt" -k --max-time
300
 -H "User-Agent:" -H "Host:" -H "Pragma:" -H "Accept:" -H "Content-Length:"
-H "
Content-Type:" -H "Expect:" --data-binary "@myinputdata.txt" >
myreplydata.txt

File "myinputdata.txt" is fixed-length text, with no appendages.

Note that all of the -H options have been included as shown per XYZ
company's instructions; this format has worked for them previously, and
still does -- as long the data being sent is XML. Also note that we are not
trying to emulate a browser because the server is not running as a web site,
and is not accessible from any browser.

For the fixed-length data version, I have run out of variations to the
command to try. Any ideas?

Thanks. -Rob

-----Original Message-----
From: Daniel Stenberg [mailto:daniel_at_haxx.se]
Sent: Thursday, April 19, 2007 11:33 PM
To: rob_at_mfals.com; the curl tool
Subject: Re: Using curl https to Post Fixed-Length Text Data -- Unable to
Get Response Data

On Thu, 19 Apr 2007, Rob Moretti wrote:

> curl <https://cert.xyzcompany.com:99999>
> https://cert.xyzcompany.com:99999 --cacert "certfile.txt" -k
> --max-time 300 -H "User-Agent:" -H "Host:" -H "Pragma:" -H "Accept:" -H
"Content-Length:" -H "Content-Type:" -H "Expect:"
> --data-binary "@myinputfile.txt" > myoutputfile.txt

Disabling Host: and Content-Length: ? That seems... wrong.

> The -i option did cause a one-line HTTP header to be saved in
> myoutputfile.txt. The content of this file was:
>
> HTTP/1.1 200 OK

That sounds like a broken server (side script). I would expect a response to
also include a few headers, successful or not.

If I were you, I'd try harder to look like a browser when sending the
request, based on what LiveHTTPHeaders show you... Most often this kind of
stuff happens because the server tries to figure out what browser that
operates on it, and when it fails to detect one it likes it goes bananas.

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