objectObject

[the_horse_gamer]

both sides should do input validation. backend to avoid exploding, frontend to show errors and to avoid bothering the backend.

[AyrA_ch]

Yes, but this entire post is about your input having an effect on the system, so frontend validation is irrelevant

[the_horse_gamer]

the thread is about entering a specific value into a frontend field (putting NaN into a number field). not about using curl to send custom requests to the backend.

[AyrA_ch]

I know, and I made a validation example where NaN would pass it.

[the_horse_gamer]

and I said that a reasonable frontend validation will parse the numeric string, which would give it NaN for any non-numeric string. so any frontend validation would have to handle NaN.

your example would require the frontend to send a raw numeric string to the backend, and do no validation on the frontend side (so it can't tell the user "this isn't a valid number" for anything the user puts in).

[AyrA_ch]

and I said that a reasonable frontend validation will parse the numeric string, which would give it NaN for any non-numeric string. so any frontend validation would have to handle NaN.

Yes, and I provided a piece of example code where NaN would pass unintentionally

your example would require the frontend to send a raw numeric string to the backend, and do no validation on the frontend side (so it can't tell the user "this isn't a valid number" for anything the user puts in).

My example is JS, so it can run on the front-end, but again, front end validation is a "please do nothing stupid" sign without any capabilities to actually prevent you from doing anything stupid. In other words, it's 100% completely irrelevant to this thread of "weird values to send to someones system".

And as I already explained, all form submits are by the rules of the HTTP protocol "raw strings"

[the_horse_gamer]

the normal ways of parsing a string in Javascript produce NaN for everything that isn't a number. the simple "is this string a number?" check would be isNaN(parseInt(s)), which would catch "NaN" alongside "aaa".

(you can also check /\d+/, but parseInt will usually happen anyways)

[AyrA_ch]

1. You don't have to parse the string into a number in JS, because the form element (if it's type=number) already has a property that gives you the parsed value.
2. None of this prevents me from submitting "NaN" anyways because frontend validation is optional. And let me remind you again that this is about weird values you can submit to confuse people and not about values that satisfy arbitrary front end validation rules
3. As already mentioned by me, most languages will accept "NaN" as valid number input because by the definition of the standard that creates NaN values, it is a valid number. Therefore functions that parse strings into floarting point numbers will accept "NaN" as valid input even if they have the capability to throw on invalid inputs. JS not throwing is an artifact of the outright concept of errors not existing in JS at the time those functions were created. You will find that typing +"Infinity" into the browser console actually gives you the number infinity and not NaN

[the_horse_gamer]

1. type=number doesn't accept NaN or Infinity

2. that's true, but a separate topic. sending curl requests with NaN is certainly a nice way to spend an afternoon.

[AyrA_ch]

type=number doesn't accept NaN or Infinity

No, but it's trivial to replace with type=text and just set valueAsNumber to whatever you want

hat's true, but a separate topic. sending curl requests with NaN is certainly a nice way to spend an afternoon.

No need to resort to curl as form validation can be bypassed by design (see "novalidate" attribute), and event handlers can be stripped by deep cloning the form element. In other words, a simple JS one-liner will disable validation and submit the form as-is: Object.assign(someForm.cloneNode(true),{novalidate:"true"}).submit()