ID: 48219 Comment by: codeslinger at compsalot dot com Reported By: carsten_sttgt at gmx dot de Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 5.*, 6CVS (2009-05-09) New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [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??? ------------------------------------------------------------------------ [2009-05-15 00:14:44] carsten_sttgt at gmx dot de After a quick view to rfc1867.c, I found a lot of: | #if HAVE_MBSTRING && !defined(COMPILE_DL_MBSTRING) So I guess a correct behavior, according to rfc2616/rfc1867, is only possible and working, if you have the mbstring extension, and if this is not a shared extension. (why does this not work with a shared extension?) (can't test this, because this extension is always shared in my installations.) It's like bug #37860: A HTTP UA is sending such a valid POST request and PHP is answering with a status 200. And both, browser an script, must assume all is ok. Instead the data is garbled. In contrast to bug #37860, it's not defined to return a status 415, (but maybe the best solution for now?). In case of bug #37860, the return status 415 is defined for such situation. But PHP is also not doing this :-/ Also a problem, if all parts are thinking the POST request is OK. Regards, Carsten ------------------------------------------------------------------------ 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/48219 -- Edit this bug report at http://bugs.php.net/?id=48219&edit=1
