Re: Fw: RFC1867 compliance
| From: | Daniel Stenberg | 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
ech
echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'ol