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:
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?
Previous Comments:
------------------------------------------------------------------------
[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... ;-)
------------------------------------------------------------------------
[2009-05-10 17:02:30] jani@php.net
btw. Fastest way to get this implemented is by providing a patch. :)
------------------------------------------------------------------------
[2009-05-10 17:01:57] jani@php.net
Unfortunately this is a feature request so reclassifying as such.
And this is (I think :) related also to bug #37860 and maybe some
others
I couldn't find. :)
------------------------------------------------------------------------
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