Request data should exclude the `_method` parameter. about rocket HOT 7 CLOSED

It's certainly a nuanced issue. Ultimately of course you should take the one which best matches your vision for the framework. I think we can both agree that _method should be stripped though, as it has meaning to the framework and should be reserved.

from rocket.

Ah, interesting. I initially had the form derivation warn, but not error on fields in a form when the structure didn't have a matching field. I later made this an error and didn't amend the _method handling. So this is a regression.

It's not clear to me what the correct thing to do here is. The real question is whether a superset of a structure should parse as that structure. It seems useful, but my reasoning before was that having 'defaultable' from values, such as Option which will parse if a value is missing, took care of this. I'm inclined to believe this is still the right thing to do.

from rocket.

The proposed solution would limit that structure to only be usable for Rocket forms. For example it would exclude the ability for someone to do #[derive(FromForm, Insertable)] if persisting via Diesel.

Do you think the user needs to be forced to care about what is otherwise an internal framework detail?

from rocket.

I may have misread your comment. I do think that having additional fields ignored makes sense, especially for forwards compatibility of APIs.

from rocket.

The proposed solution would limit that structure to only be usable for Rocket forms. For example it would exclude the ability for someone to do #[derive(FromForm, Insertable)] if persisting via Diesel.

I'm not sure which solution you're referring to, but this isn't correct either way. In fact, the todo example does just this via Option.

I may have misread your comment. I do think that having additional fields ignored makes sense, especially for forwards compatibility of APIs.

To be clear: a previous implementation ignored form fields. That is, a form submitted with fields "a" and "b" would parse into a structure with only one of "a" or "b". This is no longer the case. What I'm alluding to with Option is that if your structure contains a field of type Option, then that field is allowed to be missing from a submitted form.

from rocket.

Sorry, I will attempt to be more clear.

My first comment was that forcing something like _method: Option<String> to be present seems suboptimal, and would prevent usage of the same structure with things like Diesel which would assume that each field on the struct maps to a database column.

I think that it makes sense to allow the form data to be a subset of the sent fields without error. At minimum I would expect all forms submitted to include:

• a CSRF synchronization token
• potentially a hidden input to force older browsers to handle utf-8
• potentially a _method field

All of which are irrelevant to the user at the point that they are deserializing form input into their own structs.

from rocket.

Ah, I see where we're not communicating. I don't think applications should ever have a _method field; Rocket should definitely make that invisible. The question is: how? I see three avenues:

1. Allow any superset of incoming fields to parse into a structure.
2. Allow some superset of incoming fields to parse into a structure. In particular, only the superset that is the structure's fields + known fields, such as _method.
3. Remove known fields from the data before it gets to the parsing code.

Rocket used to do 1 but was changed (incorrectly) to 3. But it's not clear to me that's the right thing; maybe 1 or 2 are "better" solutions. You hinted at forward compatibility, which only 1 gives you. I'm not sure how big of a concern that might be in this case since applications wont use a field that doesn't exist. The upside to 1 or 2 is that it can catch errors in forms.

from rocket.