Welcome to WebmasterWorld Guest from 54.226.246.160

Forum Moderators: phranque

Message Too Old, No Replies

Effect of an empty field on form submission

     

adamas

8:52 am on Sep 20, 2006 (gmt 0)

10+ Year Member



From the HTML spec

If a control doesn't have a current value when the form is submitted, user agents are not required to treat it as a successful control.

Would I be right in thinking that this means that it is legal for an empty text field to be either included or not included in a form submission?

kaled

9:09 am on Sep 20, 2006 (gmt 0)

WebmasterWorld Senior Member kaled is a WebmasterWorld Top Contributor of All Time 10+ Year Member



Reading the quote, it implies that empty controls can be ignored when submitting for data.

My experience is that typically they send name= : I would prefer it to be otherwise.

Kaled.

pixeltierra

5:13 pm on Sep 20, 2006 (gmt 0)

5+ Year Member



I use forms a lot and rely on "" to mean something was deleted. I've never had issues. And by the way is " " not empty? You could try placing a value=" " instead of value="" as a default and see if that insures your empty value.

sharbel

10:51 pm on Sep 20, 2006 (gmt 0)

10+ Year Member



And by the way is " " not empty?

No, " " is not an empty string.. the space counts.. an empty string would be a totally blank empty box. When validating a form entry for a required field, it's always helpful to trim the string (remove whitespace from beginning and end) then check if the string is empty again, to avoid blank submissions.

adamas

10:14 am on Sep 21, 2006 (gmt 0)

10+ Year Member



sharbel: interesting point that I'll bear in mind when checking for valid input.

pixeltierra: What I'm concerned about is that the spec appears to leave open 2 possibilities for submitting empty values.

i) a=a_value&b=&c=a_value
ii) a=a_value&c=a_value

I was wondering whether either of the above can be relied upon to always be the case? Does it change according to method? I'm using POST.

It was curiousity mainly. I can easily code to allow for both possibilities and I think it would be safer to do so. Even if one can be relied upon today you never know what a new user agent might do tomorrow!

sonjay

2:23 pm on Sep 21, 2006 (gmt 0)

10+ Year Member



Yes, you should code to allow for both possibilities, and more. Anyone can POST any name/value pairs to your form script. If you gave me the URL of your form, in a few minutes I could make a form on my own computer that would POST a=a_value&c=a_value&d=myownvalue&f=someothervalue to your form processing script. Easy as pie, anyone with the most rudimentary skills can do that.

Always check user input. Check for fields that you expect to be there, and write your code so that it ignores anything you don't expect to be there.

adamas

12:48 pm on Sep 22, 2006 (gmt 0)

10+ Year Member



Even that isn't necessary these days for probing. Just a copy of Firefox and the UrlParams extension is what I generally use for testing my forms.

This one however is going to be a mega pain in the backside to test as I'm specifically coding secure forms where the fieldnames change every time you load the form and each set of names can only be submitted to once.

I don't think anybody has actually exploited my current forms yet but I've certainly seen a few exploratory manouvres.

alfaguru

1:05 pm on Sep 22, 2006 (gmt 0)

5+ Year Member



secure forms where the fieldnames change every time you load the form and each set of names can only be submitted to once

Do you need to go to such lengths? A single hidden field value will do the same job, surely. Personally, though, I'd use session variables.

 

Featured Threads

Hot Threads This Week

Hot Threads This Month