Commit 715950c
committed
[REM] website: test case for a form key ending with
In that case Werkzeug 3.0.4 and later will drop the entire
name (following pallets/werkzeug#2939, cf pallets/werkzeug#3032),
we'll end up with a field named `None` on the python side, and then
dispatching will blow up because `None` is not a valid kwarg.
The exact semantics of that case are unclear (see also
curl/curl#7789), my reading is that [RFC 7578][1] specifies
percent-encoding and thus that should be used when encoding and
decoding, and `\` should be irrelevant because it's neither `%` nor
`"` so it's not a metacharacter for multipart/form-data headers.
However the [whatwg living standard][2] rejects full blown
percent-encoding, and instead uses percent-encoding on just a highly
restricted set of inputs (which includes neither `\` nor `%`).
And while it seems like we should be able to ignore RFC 6266 (the
content-disposition header) who's to say that there are no real-world
deployments which follow its strictures?
Meh.
[1]: https://datatracker.ietf.org/doc/html/rfc7578#section-2
[2]: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#multipart-form-data
Part-of: odoo#220858
Related: odoo/enterprise#91149
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>\
1 parent b950ed8 commit 715950c
2 files changed
Lines changed: 0 additions & 7 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1124 | 1124 | | |
1125 | 1125 | | |
1126 | 1126 | | |
1127 | | - | |
1128 | 1127 | | |
1129 | 1128 | | |
1130 | 1129 | | |
| |||
1138 | 1137 | | |
1139 | 1138 | | |
1140 | 1139 | | |
1141 | | - | |
1142 | | - | |
1143 | | - | |
1144 | | - | |
1145 | | - | |
1146 | 1140 | | |
1147 | 1141 | | |
1148 | 1142 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
65 | 65 | | |
66 | 66 | | |
67 | 67 | | |
68 | | - | |
69 | 68 | | |
70 | 69 | | |
71 | 70 | | |
| |||
0 commit comments