Re: Fw: RFC1867 compliance

From: Date: Thu, 01 Jan 1970 00:00:00 +0000
Subject: Re: Fw: RFC1867 compliance
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-34437@lists.php.net to get a copy of this message
On Fri, 6 Oct 2000, Rasmus Lerdorf wrote: > 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. That's not how I interpret it. > 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. I read that paragraph as a specification of what multipart MIME type sections can contain. But what more is, I think the presence of whatever header there should be accepted, in good old MIME header tradition. I think you should parse and behave accordingly for the headers you do recognize, support and understand. If you get unexpected or unsupported headers, you should read them and ignore them. > Does it work with PHP if you do not send that Transfer-encoding header? Yes. If I have the header there, PHP assumes the image data starts already before the headers have ended and thus the image data gets ruined. I may wrongly add the content-transfer-encoding header, but you are wrongly not swallowing it. Please, feel free to correct me if I'm wrong. I don't have any really strong opinion, I can just as well cut out the content-transfer-encoding headers for PHP compatibility. -- Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77 echecho xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'ol

« previous php.dev (#34437) next »