Re: Fw: RFC1867 compliance

As far as I interpret RFC1867 you should only be sending Content-Transfer-Encoding headers if you sending a multipart/mixed block within your multipart/form-data block. The relevant text from the RFC is: multipart/form-data contains a series of parts. Each part is expected to contain a content-disposition header where the value is "form- data" and a name attribute specifies the field name within the form, e.g., 'content-disposition: form-data; name="xxxxx"', where xxxxx is the field name corresponding to that field. Field names originally in non-ASCII character sets may be encoded using the method outlined in RFC 1522. As with all multipart MIME types, each part has an optional Content- Type which defaults to text/plain. If the contents of a file are returned via filling out a form, then the file input is identified as application/octet-stream or the appropriate media type, if known. If multiple files are to be returned as the result of a single form entry, they can be returned as multipart/mixed embedded within the multipart/form-data. Each part may be encoded and the "content-transfer-encoding" header supplied if the value of that part does not conform to the default encoding. That is, I read that 3rd paragraph to be a continuation of the multipart/mixed block and it is saying that each part within a multipart/mixed can have an encoding type specified. Does it work with PHP if you do not send that Transfer-encoding header? -Rasmus On Fri, 6 Oct 2000, Sterling Hughes wrote: > 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/ > > > > > > > > >