Can an input field have a blank name?

[Clive Backham]

I'm having trouble with Instant Payment Notification on PayPal. One of
the forms that they generate, which invokes one of my scripts, has a
submit button with a blank name. The HTML fragment is this:

<input type="submit" name="" value="Continue">

This causes the FORMDATA that is sent to my script to start like this:

=Continue&nextparam=value&....

My initial reaction was that this can't possibly be valid HTML, but I
put together a brief page including such a field and submitted it to
W3.ORG's validator, and it was reported as "tentatively valid". So now
I'm led to believe that having a blank name on an input field is
valid.

But how is the received script supposed to parse it? What is the name
of the field? Is the receiving script expected to just invent some
random name?

Thanks for any light anyone can shed on this.

[Alan J. Flavell]

On Mon, 5 Sep 2005, Clive Backham wrote:

I'm having trouble with Instant Payment Notification on PayPal. One
of the forms that they generate, which invokes one of my scripts,
has a submit button with a blank name. The HTML fragment is this:

<input type="submit" name="" value="Continue">

This causes the FORMDATA that is sent to my script to start like
this:

=Continue&nextparam=value&....

My initial reaction was that this can't possibly be valid HTML, but
I put together a brief page including such a field and submitted it
to W3.ORG's validator, and it was reported as "tentatively valid".
Presumably, the "tentative" had some other cause than this...?
So now I'm led to believe that having a blank name on an input field
is valid.
I think it probably is. Validity is good, but it's only part of the
story, and in this case it's rather a small part of the story...

Really, if you're interested in the server-side activity, then the
question of what is or isn't "valid" HTML (interesting as it might be
for its own sake) is NOT your major problem.

Server-side form evaluation *needs* to be ironclad and fully defended
against anything, and I do mean ANYTHING, that can be thrown at it,
bearing in mind that a malicious user could write their own HTML form
if they cared to, and submit it to your server. Or worse. If your
server side process can be fooled by that, then you have a security
compromise in the making: just how serious that might be depends on
what the activity is. If it's about money, then it could be serious.
But how is the received script supposed to parse it?

By executing some code?

Sorry, but this -is- a serious matter. If you don't feel up to
tackling it yet, then there's no harm in asking, and doing some
exercises; but please don't put it on the live web until it's
battle-hardened. Which really isn't an HTML problem as such (you'd be
more at home on a group that handles server-side processing - maybe
comp.infosystems.www.authoring.cgi - beware its automoderation bot).

good luck

[RobG]

Clive Backham wrote:

I'm having trouble with Instant Payment Notification on PayPal. One of
the forms that they generate, which invokes one of my scripts, has a
submit button with a blank name. The HTML fragment is this:

<input type="submit" name="" value="Continue">

This causes the FORMDATA that is sent to my script to start like this:

=Continue&nextparam=value&....

My initial reaction was that this can't possibly be valid HTML, but I
put together a brief page including such a field and submitted it to
W3.ORG's validator, and it was reported as "tentatively valid". So now
I'm led to believe that having a blank name on an input field is
valid.
The name attribute is not required for input elements to conform to the
HTML DTD. The value of the attribute is CDATA, therefore an empty
string is valid. Therefore not having a name attribute, or having a
name attribute with a value that is an empty string, is valid HTML.

However, a name attribute is required for a form control to be
successful. If it doesn't have a name, its value will not be sent when
the form is submitted. In your case the name is an empty string, so the
submit button's delimited name/value pair is: &=continue

But how is the received script supposed to parse it? What is the name
of the field? Is the receiving script expected to just invent some
random name?
Presumably your receiving script will parse the returned record and
extract name/value pairs. How you deal with missing names is up to you,
but as Alan suggests, you really need specialist help when it comes to
e-commerce sites and payment systems - they must be utterly bullet-proof.

Thanks for any light anyone can shed on this.

--
Rob

[Tom Potts]

It may be valid html but why not give it a name?
Also be aware that it breaks accessability rules as it is as test and
sound and braille browsers (etc) may not be able to convey the meaning
of the button to the user.

[Nick Kew]

Clive Backham wrote:

But how is the received script supposed to parse it? What is the name
of the field?

It was a submit button. The control has only one possible value for
a given form[1], and it is not relevant to the processing script.

In any case, "" is a perfectly legitimate value for a string, and is
not a problem to parse.

[1] Given that, for this purpose we have no interest in someone who
hacks up a request that doesn't come from the form and a browser.

--
Nick Kew

[Clive Backham]

Thanks to everyone for their help with this. I was basically just
trying to find out whether a blank name attribute in an input tag is
valid. Now that I know that it is, I have fixed the parsing in my web
server scripting.

One of you mentioned that the scripting needs to be bullet-proof.
I agree. It's just that sometimes the kind of bullets that arrive are
unpredictable.

Interestingly, the problem didn't arise when the submitting browser
was Internet Explorer: it seems to treat an explicitly blank name
attribute as if the attribute were not present at all, and doesn't
send that field in the formdata. I presume that Firefox's behaviour is
correct.