maybe $HTTP_RAW_POST_DATA is what you are looking for?

btw: please define "behave correct on select multiple"

what is so bad about specifying that you are going to
fill an array? the alternative would be to create arrays
if multiple values are set while single selections 
would still become simple strings as there is no way for
PHP to know that it was generated from a <select multiple>

so it's just a tradeof: having to type two more characters
as element name or taking care that both string and array
inputs are supported in the form processing code

our approach is obviously the first one 

The problem here is not really needing to type the extra two characters, but that the resulting name/id is *not* *in* *conformance* *with* *HTML4.0*, which states that:

> ID and NAME tokens must begin with a letter ([A-Za-z])
> and may be followed by any number of letters, digits
> ([0-9]), hyphens ("-"), underscores ("_"), colons (":"),
> and periods (".").  [http://www.w3.org/TR/html401/types.html#h-6.2]

So we either have to write non-conformant HTML (not even permitted at some sites!), or program round it (e.g. by naming form elements foo_1, foo_2... and then searching for them in a loop), which is inefficient.

Besides this one, bugs #10502, #15498 and #16195 are all OPEN feature requests for the "automatically convert to array" functionality, so there is a fair level of demand for it.  Besides, a language that claims to be "especially suited for Web development" [http://www.php.net/] should not actually prevent the writing of standards-conformant Web pages.

I wish I had the spare time to investigate the PHP sources and write a patch for this myself, but I just don't.  (I only just find time to read the lists most days, but sometimes I even have to dump 100s of messages unread!)

Cheers!

Right. We need a standards-compliant, alternative syntax 
for the current array[] feature. The magical convert-all-
multiply-defined-vars-to-an-array stuff isn't going to 
happen. There are just too many issues to deal with on that 
road.

After a brief debate on #php.bugs, it looks like the only 
suitable alternative syntax would be

array-key- = value

or

array_key_ = value

i.e. substituting a hyphen or an underscore for the square 
brackets. This way we'd be compatible with the "Namespaces 
in XML" recommendation (at http://www.w3.org/TR/REC-xml-
names/) which gives meaning to colons in name tokens.

The place to implement this would be 
php_register_variable_ex() in main/php_variables.c. There 
will be a small performance penalty.

The claim that [] violates html 4.0 is simply wrong.
The html 4.0 specification clearly states that the name
attribute for the input tag is of the type CDATA and not
of type ID/NAME.

here is the url:

http://www.w3.org/TR/html401/interact/forms.html#h-17.4

Or with XHTML 1.1:

http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_extformsmodule

NAME = CDATA here too

Damn, you're right!

That'll teach me to read specs more closely (and not to believe everything everyone tells me!!).

OK, forget this one for me -- but how about closing or won't-fix-ing all those open feature requests?

Cheers and sorry for the bother!

HTTP_RAW_POST_DATA is set only when ***file*** is uploaded or somthing like that. There is no HTTP_RAW_POST_DATA if method is POST and enctype is standard - "application/x-www-form-urlencoded". I'm looking for query string (without `?' at the beginning) that is passed after HTTP request header when POST method is used.

> btw: please define "behave correct on select multiple"

I mean PHP should "parse" select multiple results correctly, because now it isn't, for example:

GET /foo.php?bar=dot&bar=com HTTP/1.0

In PHP sciript, there's only last value: $_GET["bar"] is "com". $_GET should look as below:

array(
  "bar" => array(
    0 => "dot",
    1 => "com"
  )
);

...IMO of course. I tought about creating array from EVERY VARIABLE that is passed, so request:

GET /foo.php?a=b HTTP/1.0

should (I say again - IMO) give $_GET array looking like that:

array(
  "a" => array(
    0 => "b"
  )
);

...people who like "easy programming" will use some custom functions to make access more simple, the functions like that:

function makeEasierAccessToRequestArray($arr) {
  foreach($arr as $key => $arrOfVals) {
    if (sizeof($arrOfVals) === 1) {
      $arr[$key] = $arrOfVals[0];
    }
  }
  return $arr;
}
$GLOBALS["_MYGET"] = makeEasierAccessToRequestArray($_GET);

Next thing:

> After (...) it looks like the only suitable alternative
> syntax would be
> array-key- = value
> or
> array_key_ = value
> i.e. substituting a hyphen or an underscore for the
> square brackets. (...)

Why PHP developers are so inclined to create MAGIC BEHAVIOURS and PHP-ONLY EXCEPTIONS (for example MAX_FILE_SIZE or arr[] multiple values)?
I'm against MAGIC RULES so if someone will tell me, that he has created forms making output like this:

GET /foo.php?arr[0][0]=foo&arr[0][1]=bar&arr[1][0]=dot&arr[1][1]=com HTTP/1.0

and he like to use arrays obtained from (*fucked*, being plainspoken) query-string parser from PHP, WHY HE DON'T CREATE HIS OWN LIBRARY, THAT CAN PARSE QUERY STRING AS ABOVE FOR HIS EASY USE? I see no problem:

<?php
  function escaper($regs) {
    return '$GLOBALS["GET"]["' . addslashes($regs[1]) . '"] ' . $regs[2] . ' "' . addslashes($regs[3]) . '";';
  }
  eval(preg_replace_callback("/([^=]+)(=)([^&]*)/", "escaper", $QUERY_STRING));
  // it works like that: query string == "a=b",
  // then it evals code: $GLOBALS["GET"]["a"] = "b";
  // it use escaped vals, so there's no possibility
  // to call function within query string or to make
  // parse error, for example specyfying query string
  // like that: `"=foo', becuase code generated then
  // will look like that: $GLOBALS["GET"]["\""] = "foo";
?>

Yes, and we're in the same place. WHAT WITH POST'ED VALS?! EXACTLY! If $_SERVER["SERVER_METHOD"] will be "POST" there will be no possibility to parse it manually, will the best will in the world! Why? Because there is no possibility to access HTTP-Request data RAWLY!

IMHO language should be clean and logical, without ANY EXCEPTIONS AND MAGIC BEHAVIOURS. What PHP programmer will do, it's his business, not EVERYONE WHO WANT TO USE PHP.

So, after my long lecture I await, there SHOULD NOT be alternative to syntax to `arr[]', because it would be MAGIC BEHAVIOUR. If someone will send request:

GET /foo.php?array-key-=value&multi=1&multi=2 HTTP/1.0

$_GET should look like that:

array(
  "array-key-" => "value",
  "multi" => array(
    0 => "1",
    1 => "2"
  )
);

I propose this way instead of creating every value multiple (I wrote about it before), becuase THIS LAST METHOD will not collide with every PHP-programmer habits.

we can talk about preserving POST DATA in all cases
but parameter parsing behaviour will definetly stay
as it is 

backwards compatibility alone would justify this

there is nothing magic about the parameter parser,
it assigns values to variables, and if a query string 
has multiple assignments to the same parameter name then the last one wins, thats it

*if* browsers would tell what field type input came from we could talk about automaticly creating arrays for SELECT MULTIPLE and CHECKBOX groups, but fact is that they don't

and making everything an array is simply not an option

we have even found out that we are not even violating
HTML or XHTML standards with our naming conventions 
(although we believed that for quite some time), 
so the only real reason for changing things has gone

the advantage of PHP is exactly that you *don't* have
to parse query strings or post data yourself,
hey, we even transparently parse different post encodings for you, like multipart/form-data for file uploads or application/vnd.fdf for form data sent by acrobat reader 
(and you can register even more POST data handlers based on Content-Types on the C extension levels)

Btw: MAX_UPLOAD_SIZE is a broswer thingy and we clearly document this in the "file upload" feature section in our manual

> we can talk about preserving POST DATA in all cases
> but parameter parsing behaviour will definetly stay
> as it is 

why? (see below...)

> backwards compatibility alone would justify this

Hmmm... so, if something was bad before, it must stay for backwards compatibility?! That's funny ;)
IMO PHPDevTeam should give NEW way to access variables from request in PHP, that will give "backwards compatibility" (of course; recent access methods will be accessible all the time), but with new functionality.

> there is nothing magic about the parameter parser,
> it assigns values to variables, and if a query string
> has multiple assignments to the same parameter name then
> the last one wins, thats it

Anyone can deduce, that IF BROWSER SENDS MULTIPLE VALUES WITH THE SAME NAME IT MAY MEAN THAT ALL OF THESE VALUES HAS TO BE ACCESSIBLE FOR THE SERVER-SIDE PROGRAM! There's nothing logical in your opinion. But I hope, fighting the windmills (as your conviction about "last-value = winner") may bring the new quality to PHP:

> *if* browsers would tell what field type input came from
> we could talk (...), but fact is that they don't

Standards doesn't say about TYPES in HTTP query string. Forgive me my inquirity, but everything seems, that as I wrote about it above - if BROWSER SEND MULTIPLE VALUES WITH THE SAME NAME (...), uh, maybe this (http://www.microsoft.com/windows2000/en/server/iis/default.asp?url=/windows2000/en/server/iis/htm/asp/vbob4fl9.htm) will help You to understand... I know - maybe learning PHP developer based on ASP example isn't so happy idea but slowly, I'm loosing faith in PHP...

> and making everything an array is simply not an option

look above.

> the advantage of PHP is exactly that you *don't* have
> to parse query strings or post data yourself

If some feature is *forced* and *auto-off*, that isn't an advantage.
Let's look on this case from other side: if I have a script, that is awaiting for ID parameter in query string, and someone will POST a file to it... what do you think about performance of that operation? Sorry, I found a better example: it's not a file, but a lot of parameters and values - let's say 1,5MB! IMO script shouldn't parse it automatically. IT DOES BECAUSE OF THAT "ADVANTAGE" DEPENDS ON AUTO-ACCEPT POLICY!
There's a big problem - PHP script makes all values "accessible" just at start. Apache does handle request, because it is HTTP server, so performance cost is well-founded, but PHP should give "400 Bad Request" if there's something not-needed that is passed to it, whether it is file, post data or just a query string.

> hey, we even transparently parse different post encodings
> for you, like multipart/form-data for file uploads or
> application/vnd.fdf for form data sent by acrobat reader
> (and you can register even more POST data handlers based
> on Content-Types on the C extension levels)

WOW! And, in Your opinion that's an advantage???!!! IMVHO it's a BUG because there are lot of performance costs - OK, HTTP server has the file already in RAM, but WHY PHP DOES PARSE AND CALCULATE IT AUTOMATICALLY?!

> > the advantage of PHP is exactly that you *don't* have
> > to parse query strings or post data yourself
> If some feature is *forced* and *auto-off*, that isn't an
> advantage.

excuse me, I mean "auto-on", not "auto-off"...

You obviously shouldn't be using PHP..

Let's say that's "enough good argument" to change status of this bug to "bogus". This argument tells something about whole PHP team, in fact - about discarding real arguments. I repent of learning PHP... and, as everything seems even Zend Engine 2.0 will not help on fact, that team isn't able to discuss and think...
Once again, excuse my english... maybe the last one :-S

It is not possible for PHP to magically create Arrays.

It will a) break scripts, because they will not expect an Array.

It will b) break scripts, because some versions of IE think its better to send all variables 2 times in some situations.

and btw....
even if your HTTP sends a 404 or whatever reply, it has still to discard the whole posted block. And as long the server has no 10 GBit connection this will be the bottleneck, not the parsing.

> It is not possible for PHP to magically create Arrays.

You mispelled: not "magically", but "logically" :)

> It will a) break scripts, because they will not expect
> an Array.

Hey, did you read this below?

> > backwards compatibility alone would justify this
> (...) IMO PHPDevTeam should give NEW way to access
> variables from request in PHP, that will give "backwards
> compatibility" (of course; recent access methods will be
> accessible all the time), but with new functionality.

I wrote this after taking backwards compatibility into consideration. So, let's give an example: someone who wrote script before, and this script was using $_GET["id"] will have ALWAYS LAST VALUE, like in old parser - and everything will be *exactly* backwards compatibile in this way of accessing values from request.
The new-way-parsed query strings will be placed for example in $_G superglobal array. And likewise - make $_POST array deprecated, and bring out new array - for example $_P.
Aha! And old method - $_GET should be deprecated like today arrays $HTTP_***_VARS are, so if someone will turn on all errors (error_reporting(E_ALL)), then notices about deprecated calls should be generated.

> It will b) break scripts, because some versions of IE
> think its better to send all variables 2 times in some
> situations.

Excuse me, what are You talking about? I didn't heard about anything like this, please, give me some link, example or some information about that issues!
But... there are walkarounds for client-side bugs, PHP-programmers can foresee their existence and apply possible the best patches. In spite of fact that the client-side bugs exist, IMO that's not the reason of not-changing PHP in the proper trend.
On the other hand, PHPDevTeam shouldn't adapt PHP language to any other (in this case client-side) bugs!!!

Please discuss stuff like this on the appropriate mailinglist and not on the bug system.