On Fri, 6 Oct 2000, Sven Rudolph wrote:

> > This is a clear indication that you're using a faulty receiving end.
>
> Well, I don't think so. upload.php3 looks like this:

> <?
> copy($userfile,"webcam.jpg");
>
> echo("Picture received\n
> <br>
> userfile-size:".$userfile_size."
> ");
> ?>

> (There aren't much possibilitys to make mistakes ;-)

I've received "bug reports" on this issue before and that time PHP was to
blame as well.

If you compile a stand-alone test of formdata.c, which is described in the
comments of its source header (it may need some tweaking), you can see for
yourself what a regular curl -F post look like.

It sends headers that PHP doesn't or at least didn't properly ignore/use.

> I tried it with Netscape and the following html-form:

[snip]

> The picture was ok and the browser displayed it properly.

Actually, the point here is not whether netscape works or not. The point is
if curl is following RFC1867 or not. I think netscape is following the RFC,
it just doesn't send the same header(s) as curl do.

> Maybe the commandline options I used aren't right to simulate the above
> html-form?

The options are right. The receiving end did not behave the way curl expects
it to.

Now, one could argue that curl should be modified to behave just as netscape
in this case, but I don't think that's a complete solution. That would solve
it for now, but at later time another program or application would go break
it again.

I think someone should take a look at the curl HTTP POST stream, compare it
to RFC1867 and point out who's doing the "right" thing.

As a counter-example, the CGI.pm perl module receives files posted perfectly
well, even when using curl as described above.

-- 
  Daniel Stenberg -- curl project maintainer -- http://curl.haxx.se/