From Newsgroup: alt.comp.software.firefox

Hello all.

Below is a bit of HTML, which, when more than one item is selected, results
in multiple "language" variables with different contents.

Question : Is it possible to tell it to use unique variables (preferrable
some auto-incrementing index, but will take all solutions).

I've already tried to move the "name ="..." part from the SELECT to the OPTIONs, but that didn't quite work

<form action="http://localhost/test.htm" method=get>
<select name="language" id="lang" multiple>
<option value="javascript">JavaScript</option>
<option value="php">PHP</option>
<option value="java">Java</option>
<option value="golang">Golang</option>
<option value="python">Python</option>
</select>
<input type="submit" value="Submit" />
</form>

Regards,
Rudy Wieser


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

R.Wieser wrote:

Question : Is it possible to tell it to use unique variables (preferrable some auto-incrementing index, but will take all solutions).

I could be wrong, but AFAIK, in HTML, a <select> element with the
"multiple" attribute will always submit one variable per selected option.

For example, selecting three items will produce something like:

language=javascript&language=php&language=python

If you want the submitted variables to have unique names, as far as I'm
aware, a common solution might be to use array-style naming perhaps.

Maybe change the name attribute to:

<select name="language[]" multiple>

This tells the browser to submit all selected values as elements of an
array. The resulting query string will look like:

language[]=javascript&language[]=php&language[]=python

Most server-side languages will automatically treat this as an array.

For example, in PHP you would read it as $_GET["language"], which will
contain an array of the selected values.

HTML itself cannot auto-increment variable names (e.g., language[0], language[1], etc.). If you try to hard-code an index, the browser will
still reuse the same name for every selected option. The array syntax
shown above is the standard and portable way to handle multiple
selections.

I could be wrong though, and I'm aware every response to Usenet is
dangerous with some people, so I hope this is taken well as intended.
--
Your money cheerfully refunded if my answer doesn't solve the problem.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

Arlen,

I could be wrong, but AFAIK, in HTML, a <select> element with the
"multiple" attribute will always submit one variable per selected
option.

Is there any other way it can be done than ?

For example, selecting three items will produce something like:

language=javascript&language=php&language=python

Yeah, thats what I've been describing.

<select name="language[]" multiple>

This tells the browser to submit all selected values as elements of
an array.

Thats bullcrap. They will still be just names, but now width some brackets added. And those are meaningless to the browser (the program that is
emitting them).

Most server-side languages will automatically treat this as an array.

And pray tell, why would a server-side language *parsing the URI* need those brackets at the end of the name, and not simply on a second same name
(without any kind of brackets) recognise it should than (obviously) be put into an array ? iow, its doesn't need those brackets.

And if you don't parse them but just feed them to an "eval()" than you're opening a humongous security hole.

Besides, some languages use round brackets for arrays, an others use curly-brackets. And though I can't remember, I'm sure some languages use pointy brackets.

HTML itself cannot auto-increment variable names

Well, than its good that its *the browser* which combines all the names and their values into a query string and attaches it to the outgoing request, isn't it ?

I could be wrong though,

Yeah, you could be.

Regards,
Rudy Wieser


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

R.Wieser wrote:

I could be wrong though,

Yeah, you could be.

Hi Gondolfo,

No problem. I provided the answer that most web developers would give.

However, given you're arguing with a point I didn't make, I'll cheerfully refund your money spent on customer support even as my answer was correct.
a. A <select multiple> always submits repeated names
b. name="language[]" is a widely used and valid convention
c. Many server-side frameworks automatically treat [] as an array
d. HTML cannot auto-increment variable names

To that, you appear to have responded as if I were claiming:
a. the browser interprets brackets
b. server-side languages require brackets
c. brackets are the only way to parse arrays
Yet, I never said any of that.

You also appear to have also shifted the discussion into:
a. "why would a server-side language need brackets?"
b. "eval() is dangerous"
c. "some languages use different bracket types"
None of which has anything to do with my original, practical answer.

Just to clarify, the bracket syntax isn't something the browser interprets. You're right about that. The browser simply sends the names and values
exactly as written.

The brackets are a convention used by many server-side frameworks so
that multiple values with the same name are grouped together without
requiring custom parsing. That's why you see it used so often.

It's not required, but it is widely supported.

If you're writing your own parser or using a language that handles
duplicate keys differently, then of course you can process repeated "name=value" pairs however you prefer. HTML itself doesn't provide a
way to auto-increment names for multiple selections, so repeated names
are the standard output.

Just offering the common approach in case it was useful, but if you don't
feel my answers are helping you, Gondolfo, I'll refrain from helping anew.
--
I strive to make every post on Usenet add value that wasn't there before.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

In alt.comp.software.firefox, R.Wieser <address@is.invalid> wrote:

[Arlen wrote]:

Maybe try:

comp.infosystems.www.authoring.stylesheets
comp.infosystems.www.authoring.html
comp.infosystems.www.authoring.cgi

Is there any other way it can be done than ?

Generate your HTML with a check box per language?

<select name="language[]" multiple>
This tells the browser to submit all selected values as elements of
an array.

Thats bullcrap. They will still be just names, but now width some brackets added. And those are meaningless to the browser (the program that is emitting them).

Concur that browser side it's the same. Some URL parsing tools, like
PHP, will not treat them as the same however.

And pray tell, why would a server-side language *parsing the URI* need those brackets at the end of the name, and not simply on a second same name (without any kind of brackets) recognise it should than (obviously) be put into an array ? iow, its doesn't need those brackets.

There's no way for the interpretation agnostic system to know if it
should be interpreted as "later value overrides earlier" (such as some
command line tools will behave) or "later value supplements earlier". In
the 1990s I wrote a URL parsing library that would concatenate values if
they appeared multiple times. That's what was useful to me at the time.

And if you don't parse them but just feed them to an "eval()" than you're opening a humongous security hole.

If you feed any part of the URL line to eval(), I have to wonder WTF you
are doing.

Besides, some languages use round brackets for arrays, an others use curly-brackets. And though I can't remember, I'm sure some languages use pointy brackets.

Consult your URL parsing library's documentation and see what hinting is correct. The Common Gateway Inteface (RFC 3875) does not provide any URL parsing direction. Just pass the whole thing unmodified to the script.

Having the same name appear multiple times was explicitly allowed by the original forms spec:

https://web.archive.org/web/19970406095801/http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/fill-out-forms/overview.html

For checkboxes and radio buttons, the VALUE attribute specifies the
value of a checkbox or radio button when it is checked. An unchecked
checkbox is disregarded completely when assembling the query string.
Multiple checkboxes can have the same NAME (and different VALUEs),
if desired. Multiple radio buttons intended to have "one of many"
behavior should have the same NAME and different VALUEs.

HTML itself cannot auto-increment variable names

HTML can't, but CSS has gotten pretty powerful these days. I saw a demo
of a 486 CPU implemented in javascript-free CSS recently. (It is not
a fast implementation, but the bear dances.)

https://lyra.horse/x86css/

Well, than its good that its *the browser* which combines all the names and their values into a query string and attaches it to the outgoing request, isn't it ?

I have to believe the GET request form interface is modelled after
command line tools, so interpretation is up to the tool handling the
GET. I'm struggling to find it now, but I know somewhere it was
specified that order of parameters in a request is allowed to be
significant, which is exacly how Unix command line processing works.

This:

find ~ -type f -name \*~ -print \! -name \~*\~ -delete

works differently than this:

find ~ -type f -name \*~ -delete \! -name \~*\~ -print

(The first prints all files ending with "~", and deletes those that don't
also start with "~"; the second deletes all files ending with "~" and
only prints those that do not start with "~". The find tool knows how to
do this without having numbered command line options.)

Elijah
------
has written URL parsers in three languages
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

On Tue, 24 Feb 2026 12:18:11 -0600, Maria Sophia wrote:

Most server-side languages will automatically treat this as an array.

I thought this brain-death was confined to PHP.

<https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/multiple>
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

Hey Arlen,

Hi Gondolfo,

Ohhh.... Should I now get mad or something ?

No problem. I provided the answer that most web developers would give.

No, you didn't. They would realise that PHP isn't the only language a HTTP server could use, and also not have suggested a change (those brackets)
which doesn't matter in the slightest.

You have given an AI answer : No idea how stuff works, tying non-related
stuff together and calling it a solution.

a. A <select multiple> always submits repeated names
b. name="language[]" is a widely used and valid convention

Did I already mention that you're tying un-related stuff together ? Thank
you for showing me/us that fine example. :-)

Regards,
Rudy Wieser


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

Eli,

Maybe try:

comp.infosystems.www.authoring.stylesheets comp.infosystems.www.authoring.html
comp.infosystems.www.authoring.cgi

Thanks. I'm not sure how authoring.stylesheets or authoring.CGI are
relevant to my question, but perhaps authoring.html is the newsgroup that
will know.

Is there any other way it can be done than ?

Generate your HTML with a check box per language?

Hmmm... That could work. I'll have to see how it looks.

But, no idea how to get that SELECT list to play nice ? Either by auto-incrementing the name for each selected item, or using the name in each OPTION ? Shucks.

Concur that browser side it's the same. Some URL parsing tools,
like PHP, will not treat them as the same however.

AFAIK the parsing of the URL is done *before* PHP (or any other language in its place) is called. The called program (PHP or something else) just gets its arguments thru its commandline or in its environment.

There's no way for the interpretation agnostic system to know if
it should be interpreted as "later value overrides earlier" (such
as some command line tools will behave) or "later value supplements
earlier".

True, but its rather common behaviour. Especially when arguments are passed by way of environment variables.

Hence my question how to get unique names from a html SELECT element.

And if you don't parse them but just feed them to an "eval()"
than you're opening a humongous security hole.

If you feed any part of the URL line to eval(), I have to wonder
WTF you are doing.

Indeed. But there are still people who will just string-append stuff coming directly from a user into SQL queries. :-) :-(

Consult your URL parsing library's documentation and see what
hinting is correct. The Common Gateway Inteface (RFC 3875) does
not provide any URL parsing direction. Just pass the whole thing
unmodified to the script.

So every kind of (scripting) language that gets the honor to do some work
for the HTTP server needs to know everything about how to handle URI's ?

I thought that the usual way to do this stuff is to have the HTTP server handle the HTTP side of it, and pass the arguments (to PHP or other) in way common to the OS.

Also, how does that work when you upload a file ? :-)

Having the same name appear multiple times was explicitly allowed
by the original forms spec:

:-) Seeing that I got an URI with multiple variables having the same name already told me that.


My current question focusses on the client side. If I can get that side to emit unique variable names I do not need to bother with handling non-unique variable names at server side.

But as that doesn't seem part of what the webbrowser can do for me I should perhaps ask that authoring.cgi newsgroup how non-unique variable names
should be/are normally handled server-side (iow, a belated thanks for mentioning that newsgroup).

Regards,
Rudy Wieser


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

Maybe try:

...

comp.infosystems.www.authoring.cgi

Damn. ES doesn't seem to carry it.

... nor does any of the other five newsgroup servers I have access to.

Regards,
Rudy Wieser


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

In alt.comp.software.firefox, R.Wieser <address@is.invalid> wrote:

Eli,

Maybe try:

comp.infosystems.www.authoring.stylesheets comp.infosystems.www.authoring.html
comp.infosystems.www.authoring.cgi

I noticed your followup that states you don't have that third one. I was subscribed once, but am not now, so if was rmgrouped I would not have
noticed.

Thanks. I'm not sure how authoring.stylesheets or authoring.CGI are relevant to my question, but perhaps authoring.html is the newsgroup that will know.

The CSS group has the most traffic (not much), and CSS is used for
things that used to be the domain of javascript once, hence the
suggestion.

But, no idea how to get that SELECT list to play nice ? Either by auto-incrementing the name for each selected item, or using the name in each OPTION ? Shucks.

The SELECT is playing by the rules that have existed since Mosaic was
the headline browser. Just because you don't like those rules, doesn't
mean it's not nice.

AFAIK the parsing of the URL is done *before* PHP (or any other language in its place) is called. The called program (PHP or something else) just gets its arguments thru its commandline or in its environment.

You are wrong. PHP gets the full query string and is responsible for
parsing the elements within it on it's own. The server only parses the
URL in to basic components like server name, script name, and arguments.

PHP has configuration options about how to parse the query string.

True, but its rather common behaviour. Especially when arguments are passed by way of environment variables.

The environment variable the web server sends looks like

QUERY_STRING=name=value&name=content&name=stuff&text=foo

for

<FORM method=GET>
<SELECT name=name>
<OPTION value="value">Value</OPTION>
</SELECT>
<INPUT type=checkbox name=name value="content">
<INPUT type=submit name=name value="stuff">
<INPUT type=radio name=text value="foo">
</FORM>

Hence my question how to get unique names from a html SELECT element.

You seem to misunderstand. Query strings were a bolt-on to the original
HTTP protocol and were never really for HTTP servers to handle.

So every kind of (scripting) language that gets the honor to do some work for the HTTP server needs to know everything about how to handle URI's ?

Yes.

Also, how does that work when you upload a file ? :-)

You use a POST with enctype="multipart/form-data" and the CGI gets a
MIME multipart form on STDIN to parse. I have written a parser to do
that, once. Unlike email MIME, the data in the multipart form is raw 8
bit instead of base64 encoded. There's an environment variable that
tells you how much data to expect (it comes from the content length
header the browser sends with the form).

These protocols are all just text. You can just spy on it.

My current question focusses on the client side. If I can get that side to emit unique variable names I do not need to bother with handling non-unique variable names at server side.

I've used javascript to write forms with incrementing values. That's an
option.

Click the "[+]" to add a new tag search field. Note the incrementing
numbers. No javascript libraries used.

<tr><td><label for=tag0>Tags</label></td>
<td><span onClick="add('tag');">[+]</span></td>
<td><input type=text size=30 id=tag0 name=tag0></td></tr>

[...]

<script>
let e={"tag":0,"xtag":0,"title":0,"desc":0};
function add(f){
e[f]++;
it=document.createElement('input');
it.type="text";
it.size=30;
it.name=f+e[f];
it.placeholder=f+" "+e[f];
it.id=it.name;
wh=document.getElementById(f+0).parentNode;
wh.appendChild(it);
}
</script>

I'll let you figure out how that works yourself. It's the fanciest
javascript I have written in years.

But as that doesn't seem part of what the webbrowser can do for me I should perhaps ask that authoring.cgi newsgroup how non-unique variable names should be/are normally handled server-side (iow, a belated thanks for mentioning that newsgroup).

These days browsers include at least two Turing-complete tools for
pages, Javascript and CSS. Browsers can do it, but you can do it on
the backend, too.

A new-school front-end engineer would probably have the submit button
run some javascript that re-writes the form data and then sends that.
Too fancy for me.

Elijah
------
has a preference for writing Perl over JS
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

Eli,

comp.infosystems.www.authoring.cgi

I noticed your followup that states you don't have that third one. I
have was subscribed once, but am not now, so if was rmgrouped I would not noticed.

Or your newsgroup server still carries it. I just wanted you to be aware that, in that case, its not universially carried (and perhaps getting
another suggestion).

The CSS group has the most traffic (not much), and CSS is used
for things that used to be the domain of javascript once, hence
the suggestion

I'm not at all sure how CSS can cause a dynamic change in the DOM ... Maybe
I should just put my question in that newsgroup and find out.

But, no idea how to get that SELECT list to play nice ? Either
by auto-incrementing the name for each selected item, or using
the name in each OPTION ? Shucks.

The SELECT is playing by the rules that have existed since Mosaic
was the headline browser. Just because you don't like those rules,
doesn't mean it's not nice.

But, but, but ... They should have *known* I wanted it to behave my way,
and implemented it. That is how it works, right ? :-)

To be honest, its possible that what Arlen described, putting those blockquotes after the name (and let the server figure it out), was *the* way it was supposed to be done. Though I can't seem to google anything in that regard. :-\

You are wrong. PHP gets the full query string

Nope. You forgot the word "also". PHP *also* gets the full *query*
string - as a result of the HTTP server having put it into an environment variable before calling the program/script to handle the request.

Just think of how a file-upload would work if PHP would be doing all the
heavy lifting. No, what PHP (or any other program/script in its place) gets is all pre-chewed.

The environment variable the web server sends looks like

QUERY_STRING=name=value&name=content&name=stuff&text=foo

Yes, exactly. The *web server* - or rather: the HTTP server - puts the raw query string into the environment of the script/program it calls to handle
the request.

At that point the HTTP server has also added slew of other environment variables, including the ones with the names and values of the variables in the URI it received.

Hence my question how to get unique names from a html SELECT
element.

You seem to misunderstand. Query strings were a bolt-on to the
original HTTP protocol and were never really for HTTP servers
to handle.

Lots of things, inlcuding Javascript, CSS and a number of HTML elements,
where bolted on. That is why we got a whole list of RFCs about them.

And I think you misunderstood : my question was about if what I asked for *currently* exists, not if it was part of the specs in the nineteeneighties.


But, as having the webbrowser modify those names to make them unique (or allowing me to provide unique names in the OPTION elements themselves) does not seem to exist, I'll have to rewrite that part of my http server to
handle them instead.

Regards,
Rudy Wieser


--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

In alt.comp.software.firefox, R.Wieser <address@is.invalid> wrote:

You are wrong. PHP gets the full query string

Nope. You forgot the word "also". PHP *also* gets the full *query*
string - as a result of the HTTP server having put it into an environment variable before calling the program/script to handle the request.

There are a slew of variables, but there is not a parsed query string.
PHP does the parsing. It searches for the separator and the equals sign
itself, and decides if something should be treated as a regular variable
or an array based on finding square brackets.

I invite you to inspect the code:

https://github.com/php/php-src/blob/master/main/php_variables.c

You can get a glimpse of the parsing the server does by looking at the
server variables in the environment. (PHP as a module, versus PHP as a
CGI may get those differently, but that's the part done for common
gateway interface (CGI).

Just think of how a file-upload would work if PHP would be doing all the heavy lifting. No, what PHP (or any other program/script in its place) gets is all pre-chewed.

PHP does do all the "heavy lifting" for file uploads. That's why PHP has settings for controlling file upload behavior and Apache and Nginx do
not.

Apache and Nginx only have settings for total size of an upload,
based solely on size of the POST, not parsing the post. See
LimitRequestBody, for example, in Apache. The LimitRequestFields fields
right after it is about the number of header lines to parse, not the
number of variables in a query to parse, because Apache parses the
headers but not the query string.


https://httpd.apache.org/docs/2.4/mod/core.html

The environment variable the web server sends looks like

QUERY_STRING=name=value&name=content&name=stuff&text=foo

Yes, exactly. The *web server* - or rather: the HTTP server - puts the raw query string into the environment of the script/program it calls to handle the request.

We agree on this.

At that point the HTTP server has also added slew of other environment variables, including the ones with the names and values of the variables in the URI it received.

We disagree on this. I submit that you _cannot_ find official
documentation or major brand server source code implementing this behavior
you claim exists.

But, as having the webbrowser modify those names to make them unique (or allowing me to provide unique names in the OPTION elements themselves) does not seem to exist, I'll have to rewrite that part of my http server to handle them instead.

Are you writing your own web server or something? If not, what software stack are you looking at?

Elijah
------
CGI very explicitly leaves query parsing to the cgi-bin program
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: alt.comp.software.firefox

On Fri, 27 Feb 2026 07:09:21 -0000 (UTC), Eli the Bearded wrote:

There are a slew of variables, but there is not a parsed query
string. PHP does the parsing. It searches for the separator and the
equals sign itself, and decides if something should be treated as a
regular variable or an array based on finding square brackets.

PHP is full of stupid things.

PHP does do all the "heavy lifting" for file uploads.

Maybe it does too much. I wrote a network-based file-management
interface as part of a corporate intranet app. It was capable of
handling large (multi-gigabyte) file uploads and downloads. A key
point was minimizing the number of copies (and amount) of the data
that needed to be kept around during transfers.

I didnrCOt write it in PHP; I used Python.
--- Synchronet 3.21b-Linux NewsLink 1.2