Edit report at http://bugs.php.net/bug.php?id=48219&edit=1
ID: 48219 Updated by: [email protected] Reported by: carsten_sttgt at gmx dot de -Summary: POST data is not decoded, according to Content-Transfer-Encoding +Summary: Add entry for possible content-transfer-encoding in uploaded file information Status: Open Type: Feature/Change Request -Package: Feature/Change Request +Package: HTTP related Operating System: * PHP Version: 5.*, 6CVS (2009-05-09) Block user comment: N Private report: N New Comment: Updated, shouldn't it be enough if we add the encoding if it is passed by the uploader? Then you could handle the data easier. Any other fields that are missing? :) I don't think PHP should decode it automatically.. Previous Comments: ------------------------------------------------------------------------ [2009-11-20 21:46:47] codeslinger at compsalot dot com Well, I mostly deal with email, especially including webmail. and as far as I can see, nearly all attachments are base64 encoded. In fact it is hard to find anything that isn't, unless it's plain text. So, I guess I was a little bit confused about the difference between HTTP uploads and email uploads, since they both use MIME and typically they both contain web pages. With regard to this feature request. I would really like for php to make the MIME Header info available. That way we can easily do our own decoding as long as we have access to the info that tells us what needs to be decoded, currently we don't, at least not with out kludge hacks, and that makes it hard to do something which should be simple. ------------------------------------------------------------------------ [2009-11-19 23:55:12] avalon73 at caerleon dot us RFC 2616 section 3.2.7 itself says nothing about the use of Content-Transfer-Encoding (CTE). RFCs 1867 and 2388 both mention the possibility of the multipart/form-data MIME type being used with email as a transport as well as HTTP. The CTE header and the "base64" and "quoted-printable" encodings were included in MIME specifically for moving 8-bit data over 7-bit transport protocols, which included basic (non-enhanced) SMTP at the time of its creation (and still does, if you adhere strictly to the RFCs). The other standard encodings defined for the CTE header (7bit, 8bit, and binary) imply no content encoding at all. HTTP is and has always been an 8-bit clean transport protocol. Because of that, it has no need for any encodings designed to move 8-bit data over a 7-bit protocol. In fact, the use of such encodings would only needlessly add bulk to the data being transferred. If no such transformation is necessary, the addition of the CTE header is also not necessary. Section 19.4.5 of RFC 2616 would seem to merely codify this fact, effectively forbidding the use of CTE over HTTP. ------------------------------------------------------------------------ [2009-11-19 23:00:39] carsten_sttgt at gmx dot de > Has anyone noticed this? > http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.4.5 Sure, but in rfc2616-sec3.html#sec3.7.2 you can read, that especially multipart/form-data is defined in RFC1867 (RFC2388). And there you can read about the content-transfer-encoding. Regards, Carsten ------------------------------------------------------------------------ [2009-11-19 20:59:16] avalon73 at caerleon dot us Has anyone noticed this? http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.4.5 RFC 2616 is the one for HTTP 1.1, and the first paragraph reads as such: --- HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP client. --- Perhaps that's why PHP hasn't supported it, and why no browser in the real world (that I know of... I could be mistaken) ever sends base-64 or quoted-printable encoded multipart/form-data parts? ------------------------------------------------------------------------ [2009-11-18 08:23:46] codeslinger at compsalot dot com this also afflicts Base64 encoding which is a massively prevalent method for binary transfers.... I am really surprised to encounter this *bug* It means that everything php is doing with regard to saving/moving uploaded files is wasted/useless effort. Since the content transfer type is not even accessible, we must instead do our own parsing of the raw post data. How can that be by design??? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=48219 -- Edit this bug report at http://bugs.php.net/bug.php?id=48219&edit=1
