- From: dolphinling <dolphinling@myrealbox.com>
- Date: Mon, 13 Dec 2004 19:24:58 -0500
Greg Kilwein wrote: > dolphinling wrote: > >> Ian Hickson wrote: >> >>> On Sun, 12 Dec 2004, Ben Meadowcroft wrote: >>> >>>>>> I don't feel like doing a detailed readthrough of the spec again >>>>>> (though I did glance at parts that looked relevant), but is there >>>>>> anything in WF2 that allows only parts of a form that have changed >>>>>> from their default value to be submitted? >>>>> >>>>> There isn't; what would the use case be? >>>> >>>> Seriously though I recently had to frig this by adding hidden form >>>> elements using Javascript to the form on an onchange handler >>>> indicating when a field had been changed so you don't have to do >>>> lookups on the backend data first to decide if there has been a >>>> change or not. >>> >>> Be very careful with this -- you should always assume that the >>> client-provided data is hostile, and not trusted. >> >> Once again, if the data's not submitted, it can't be hostile. > > Yes, it can be, say, on a required field on a form. But in that case the data /is/ submitted (and you do validity checking, etc. on it). This is for data that's /not/ submitted, and is assumed by the server to be the default. It's logically impossible for that data to be hostile unless the default is hostile. >>> (Note that there is also the problem of how to handle checkboxes that >>> I mentioned earlier. Any proposal for how to handle this would have >>> to address that issue first.) >> >> Which problem is this? > > When a checkbox is not checked, the UA does not submit the value of the > checkbox with the form. Therefore, how is the server supposed to > differentiate between when the checkbox has been unchecked by the user > and when the UA is not submitting it because the field has not changed? > > This also creates other problems. Given a situation where a user is > editing a "comments" textarea, assume the user wants to erase the > comments. How can the server differentiate between the user > legitimately erasing the comments and the UA not submitting it because > the field has not changed? As far as I can tell, for textareas (and input type='text', etc.) The value of '' (i.e., empty) is submitted normally, so that wouldn't be a problem. For an easy workaround for the checkbox problem, input type='checkbox', 'radio', and select (any others?) could just always be submitted. Anyone else have a better solution?
Received on Monday, 13 December 2004 16:24:58 UTC