ID: 48219 Comment by: avalon73 at caerleon dot us 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:
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. Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2009-05-10 19:15:16] carsten_sttgt at gmx dot de > And this is (I think :) related also to bug #37860 Yes, it's similar. BTW. I think bug #37860 is a feature request and also a bug. - Feature: It would be nice, if PHP is decoding the data if the coding is known (see rfc2616-sec3.5/-sec14.1. e.g. if the gzip-extension is loaded and "Content-Encoding: gzip" is set in the request - Bug: if PHP can't/won't do this, it should raise/return a HTTP status code of 415. (See rfc2616-sec14.11) > Unfortunately this is a feature request so reclassifying as such. That's really something I was unsure about. See rfc2616-sec3.5. In general: | an HTTP user agent SHOULD follow the same or similar behavior | as a MIME user agent would upon receipt of a multipart type. | The MIME header fields within each body-part of a multipart | message- body do not have any significance to HTTP beyond that | defined by their MIME semantics. Well, a MIME user agent must decode such data. Because of the "should" in this statement, it /can/ be a feature request (but "should" is more restrictive than a "may" / "optional".). But same section rfc2616-sec3.5: Note: The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request method, as described in RFC 1867 [15]. And in rfc1867 (or the newer rfc2388), Content-Transfer-Encoding is explicit part of the rfc. So I think a HTTP software should know and handle Content-Transfer-Encoding. Well, Perls' CGI.pm also is not doing this ;-) BTW: In difference to the Content-Encoding, I can't see the Content-Transfer-Encoding in the script. So that can be really a problem. But using a Content-Transfer-Encoding is not usual (or is it not usual, because Perl/PHP can't handle this?) > btw. Fastest way to get this implemented is by providing a patch. :) Yeah, if my C would be better... ;-) ------------------------------------------------------------------------ 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
