actix-web: Parsing optional field seems to not work for numbers when not filled
Hello, I currently try to parse a form but I have a Parse error for a specific case:
struct TestForm {
text: Option<String>,
number: Option<u32>
}
- Whether I filled the text input field or not, it ends up being `Some(“whatever”) or ‘None’.
- When I fill the number input field (a html text input), It parses to
Some(123)
. - But when I don’t fill the number field, it fails and return a
Parse error
(aUrlencodedError::Parse
error apparently)
Same behaviour for f32 so far I’ve tested.
- Rust Version: 1.48.0
- Actix Web Version: 3.3.2
Thanks a lot for the help.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 15 (7 by maintainers)
Slightly less involved workaround:
I understand and agree that this behaviour is correct from a query parser point of view:
text&number=32
should not producetext: None
. Maybe the lib implementation is correct if you don’t consider what sends the request. But well, this is the title: x-www-form-urlencoded meets SerdeHere we are talking about
web::Form
which is a Form deserializer utility and imho it should behave like a form behaves.So, regarding browsers behaviour, a required input field is not valid until the text is not empty. From MDN:
Conversely, an empty string for an optional input (default) has no value, it is
None
then. A web form sends all data, filled or not. I think we can’t even discuss if an empty string is valuable or not, the web standard decided for us.Unfortunately, in the current implementation state, it makes the deserialization completely useless for optional inputs as we have to treat everything as
String
and do the job ourselves anyway.Absolutely not. Framework should handle this.
As this is the only open issue regarding problems with serde_urlencoded, I’m considering it a tracking issue for a remedy.
@robjtede That workaround is incredibly helpful, thank you!
In my situation, that helped me to have more graceful failures when query params aren’t right (either empty like
someNumber=
which is easy to obtain through a form with a GET action, or someone URL hacking and settingsomeNumber=asdf
in which case I’d prefer for it to just be ignored and treated asNone
rather than seeing an error page).