Fw: RFC1867 compliance

I recieved the following message from Daniel Stenberg (author of curl), any thoughts?? -Sterling Ps: You can reach him directly at daniel@haxx.se > I have had a discussion about posting files as RFC 1867 describes from curl > to a server running PHP. It is said to not work (an excerp from one of the > mails is below). > > I know I've had this kind of problem with other people before, and therefore > I thought it would be about time to discuss it with someone that knows about > PHP internals. > > The problematic RFC1867 post uses the following look: > > -------------- start of post > Content-Type: multipart/form-data; boundary=curltkPJQKjCK6PdUy9liJCXzTIka69 > > --curltkPJQKjCK6PdUy9liJCXzTIka69 > Content-Disposition: form-data; name="pic"; filename="curl.jpg" > Content-Type: image/jpeg > Content-Transfer-Encoding: binary > > [image binary data] > -------------- end of example output > > > ... the problem here seems to be that PHP assumes that the data begins right > after the "Content-Type: image/jpeg" line. > > I'm not even sure this is built-in PHP, an add-on or even if this is actually > fixed or just a user-mistake. > > There's also the possibilty that I've misinterpreted the RFC. > > -- > Daniel Stenberg -- curl project maintainer -- > http://curl.haxx.se/ > > ---------- Forwarded message ---------- > Date: Fri, 6 Oct 2000 12:27:12 +0200 (MET DST) > From: Daniel Stenberg <daniel@haxx.se> > To: Curl Mailinglist <curl@contactor.se> > Subject: RFC1867 compliance (was Re: Using -F) > > 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/ > > >