On Thu, 16 Dec 2010 14:53:08 -0000, Matthew Weier O'Phinney
<weierophin...@php.net> wrote:
On 2010-12-16, Pierre Joye <pierre....@gmail.com> wrote:
I never said it should be a php.ini option, or only a php.ini option.
But having 300 ways to do the same things, or to change options is
bad. You should also keep in mind that even if it is a php.ini option,
it should obviously be INI_PER_DIR and not system wild (that's what
servers options exist, or better appropriate there if one wants to
disable POST permanently and for all requests/URLs).
INI_PER_DIR doesn't work for, I would argue, the majority of modern PHP
applications.
If you look at most frameworks, CMS solutions, or standalone apps such
as WordPress, there's a single script acting as the gateway to all
functionality (basically, a front controller). Making the setting
INI_PER_DIR means that you have to move any functionality that may
potentially require access to raw POST/PUT data into separate scripts
and/or directories -- which splits functionality away from the front
controller and makes maintenance much more difficult.
I know you're responding to Pierre's proposed addition of a way to disable
POST data handling altogether possibly via an ini option, but since the
objection also applies to the ini option I've added to trunk, I'd like to
address it.
Yes, it sucks that the option cannot be changed with ini_set, but that's
an inevitable technical limitation that I don't see how it can be overcome
without major changes. By the time control is passed to the script, the
interesting stuff has already happened.
(By the way, I think it's unfortunate that most frameworks abandoned the
simplicity of a direct correspondence file <--> url -- whenever practical,
of course, but that's another matter)
All in all, I don't think adding a set of new ini settings for very
specific and disputable features is not something good to do. If we
need something to process file uploads more efficiently, then let do
it in a good way (no, processing php://input manually is not what I
can consider as a good way :).
As to multipart requests, we could of course build some mechanism to
provide, sequentially and in the order they are uploaded, streams for the
uploaded files; this would be easier than processing php://input manually.
It's also much more complicated to implement and doesn't cover all the
cases in which we want a way to handle multipart requests that differs
from the default behavior -- think, for instance, proxying requests.
In short, I don't think the possibility of a future implementation of more
high level mechanisms should preclude the existence of low level ones such
as the proposed and committed enable_post_data_processing, as the low
level ones, being less specific, have a larger domain of application,
despite being more cumbersome.
I'm not talking about processing file uploads; I'm talking about normal
handling of raw POST/PUT body content -- something that's very, very
common when dealing with RESTful or RPC APIs, where the format isn't
normal URL encoding, but instead something like XML or JSON.
I'm all for better, more efficient processing of file uploads -- but not
at the expense of being able to build good APIs.
I'm not sure what you're proposing instead.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
