cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: problem with HTTPS post of file: "Expectation failed"

From: Chris Dawson <xrdawson_at_gmail.com>
Date: Fri, 25 Nov 2005 09:20:39 -0800

So, I if I run this command:

curl -b jar.txt -c jar.txt --trace-ascii trace.txt -k -F
"episode[title]=Upload" -F "episode[description]=uploaded description"
https://podasp.com/episode/create

I get this:

== Info: SSL certificate verify result: error number 1 (18), continuing
anyway.
=> Send header, 347 bytes (0x15b)
0000: POST /episode/create HTTP/1.1
001f: User-Agent: curl/7.14.0 (i486-pc-linux-gnu) libcurl/7.14.0 OpenS
005f: SL/0.9.7g zlib/1.2.3 libidn/0.5.13
0083: Host: podasp.com
0095: Accept: */*
00a2: Cookie: _session_id=6e5727f3df5495a347c11e1db59fe151
00d8: Content-Length: 284
00ed: Expect: 100-continue
0103: Content-Type: multipart/form-data; boundary=--------------------
0143: --------59eb8cbb45fd
0159:
<= Recv header, 33 bytes (0x21)
0000: HTTP/1.1 417 Expectation Failed
<= Recv header, 19 bytes (0x13)

Beginning at the last four lines, the request seems truncated to me, in that
I would expect to see the "episode[title]" values placed into the multipart
request, like I see in the liveheaders output (
webcastinabox.com/projects/podasp/livehttp.txt)

Am I using the -F switch incorrectly, or misunderstanding it's utility?

Thanks,
Chris

On 11/25/05, Chris Dawson <xrdawson_at_gmail.com> wrote:
>
> I am using:
>
> curl 7.14.0 (i486-pc-linux-gnu) libcurl/7.14.0 OpenSSL/0.9.7g zlib/1.2.3
> libidn/0.5.13
>
> I'll see if I can get a regular post without a file to show me more
> headers. If I use the -F switch, do I need to provide another switch to
> curl as well when doing a multipart form POST?
>
> I should mention that curl is absolutely awesome. A command line tool
> with this incredible functionality and impeccable design is rare and
> beautiful!
>
> Thanks for your help.
>
> Chris
>
> On 11/25/05, Daniel Stenberg <daniel_at_haxx.se> wrote:
> >
> > On Thu, 24 Nov 2005, Chris Dawson wrote:
> >
> > > I'm sorry if I am being dense, but when I run with --trace-ascii, I
> > see
> > > this:
> > >
> > > 0095: Accept: */*
> > > 00a2: Cookie: _session_id=9d7d245d2f5103092266f026e870ba2b
> > > 00d8: Content-Length: 137114
> > > 00f0: Expect: 100-continue
> > > 0106: Content-Type: multipart/form-data; boundary=--------------------
> > > 0146: --------edadd7db6abb
> > > 015c:
> > > <= Recv header, 33 bytes (0x21)
> >
> > Does it really stop there? That's the first few headers of the formpost
> > request curl sends.
> >
> > > Am I wrong in thinking that it is truncating the entire message sent
> > to the
> > > server?
> >
> > --trace doesn't truncate anything. It shows the lot.
> >
> > > Obviously this would be useful because I am sending a large file and
> > don't
> > > really care to see 2 MB of base64 encoded characters, but I would
> > prefer to
> > > see at least the first few hundred to verify that my message is
> > proper.
> >
> > Then you need to patch the code, as curl doesn't offer any such way.
> >
> > > But, I don't see anything past the boundary marker.
> >
> > Then there's something really wrong.
> >
> > > Am I misunderstanding the output from trace, or is trace indicating
> > that I
> > > am not providing the proper switches to curl to add those items to the
> > form
> > > submission?
> >
> > I don't know why it would stop there. If there was a lack of switches or
> > whatever, curl is supposed to tell exactly that and not just abort a
> > request
> > in the middle.
> >
> > Did you ever mention what curl version you're using?
> >
> > --
> > Commercial curl and libcurl Technical Support:
> > http://haxx.se/curl.html
> >
>
>
Received on 2005-11-25