Edit report at https://bugs.php.net/bug.php?id=48219&edit=1
ID: 48219
Comment by: alastair at alastairs-place dot net
Reported by: carsten_sttgt at gmx dot de
Summary: Add entry for possible content-transfer-encoding in
uploaded file information
Status: Open
Type: Feature/Change Request
Package: HTTP related
Operating System: *
PHP Version: 5.*, 6CVS (2009-05-09)
Block user comment: N
Private report: N
New Comment:
The claim that HTTP, as a binary supporting protocol, does not need
Content-Transfer-
Encoding for form POSTs is bogus.
The problem is very simple; if your MIME boundary is set to (say) "test", then
a POST with
a body like this:
--test
Content-Disposition: form-data; name="frob"
$frobValue
--test--
can go wrong if $frobValue happens to contain something like
This is line one.
--test
Content-Disposition: form-data; name="hack"
This is very naughty.
This could happen from a web browser, if the boundary was predictable. It's
unlikely to
happen by accident (since in practice the boundary will be randomly generated
and contain a
significant number of characters), but it could nevertheless happen.
There are two ways to deal with this problem. The first is to set
Content-Length headers
on the subparts; the MIME parser can then read that many bytes in the knowledge
that no
*real* boundary will be within the data. The second is to use
Content-Transfer-Encoding
and either send the data as e.g. base64, or use quoted-printable in combination
with a
boundary that is not valid quoted printable data.
Unfortunately, as far as I can see from reading rfc1867.c, PHP SUPPORTS
NEITHER! Even for
binary files, PHP *ignores* Content-Length and scans for a boundary instead.
Result: there
is a statistical likelihood, however, small, that the POST data will not be as
expected.
Previous Comments:
------------------------------------------------------------------------
[2010-12-20 08:55:51] [email protected]
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..
------------------------------------------------------------------------
[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?
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=48219
--
Edit this bug report at https://bugs.php.net/bug.php?id=48219&edit=1
