As I told you, there was already a consensus on this solution, check
my initial proposal (solution #2):
No, that's a consensus on compile-time versus runtime. What I offered
in my post was four variants of how runtime could be implemented.
In response to the suggestion to just turn $_REQUEST (et.al.) into
objects with overloaded array access, the big danger there is that the
following behavior would change:It will bring a BC break as well or is_array($arrayaccessobject) will
have to return true and we have to be sure about its implementation
(like properties access not always working well).
Right, we all agree that approach won't work.
Personally, I like Option 4, but then I like complexity. I can
certainly see going for any of the others, but I want to go with
something that the rest of the group can see being appropriately useful.I like my initial proposal. All it needs is an extra function and to
move the JIT management to runtime. The complexity is the same as what
we have now.
What if I want to inspect one particular element for encoding hints?
/* Initially set encoding to ascii just for parsing 'ei' /
http_input_encoding('ascii');
if (!empty($_REQUEST['ei'])) {
/ Request identified itself /
if (!http_input_encoding($_REQUEST['ei'])) {
handle_bad_input_encoding();
}
} else {
/ Fallback on best-guess /
http_input_encoding_detect('UTF-8,ISO-8859-1');
}
/ Work with the rest of $_REQUEST using the identified encoding */
-Sara
Hello,
As I told you, there was already a consensus on this solution, check
my initial proposal (solution #2):No, that's a consensus on compile-time versus runtime. What I offered
in my post was four variants of how runtime could be implemented.
The consensus was on #2 (which is your #1).
In response to the suggestion to just turn $_REQUEST (et.al.) into
objects with overloaded array access, the big danger there is that the
following behavior would change:It will bring a BC break as well or is_array($arrayaccessobject) will
have to return true and we have to be sure about its implementation
(like properties access not always working well).Right, we all agree that approach won't work.
Personally, I like Option 4, but then I like complexity. I can
certainly see going for any of the others, but I want to go with
something that the rest of the group can see being appropriately useful.I like my initial proposal. All it needs is an extra function and to
move the JIT management to runtime. The complexity is the same as what
we have now.What if I want to inspect one particular element for encoding hints?
/* Initially set encoding to ascii just for parsing 'ei' /
http_input_encoding('ascii');
if (!empty($_REQUEST['ei'])) {
/ Request identified itself */
if (!http_input_encoding($_REQUEST['ei'])) {
it is typo right? like using a function http_input_encoding_detect_from(...)?
handle_bad_input_encoding();}
} else {
/* Fallback on best-guess /
http_input_encoding_detect('UTF-8,ISO-8859-1');
}
/ Work with the rest of $_REQUEST using the identified encoding */
Sorry but that's horrible :)
That's way too complex to handle the input enconding. PHP Unicode
functions can include some magic function to detect the encoding of a
given string but I hardly see it as a specific http function.
The two functions needed can be:
http_input_encoding: set the input encoding (UTF-8, ASCII, etc.)
http_input_encoding_error: get the error (invalid sequence, badly formed,etc.)
If we like to go with #4, I rather prefer a more drastic change and go
with something like perl/python CGI objects. And it is a piece of cake
to implement in ext/filter. #4 makes possible as well to implement #1
to minimize the impact on the existing applications (relying on GPC).
--Pierre