Fix various content type issues on LIO request helpers #297
Conversation
bdach
force-pushed
the
fix-bad-mime-type
branch
from
8edafc4 to
a29de0a
Compare
- `plain/text` is exactly backwards; it's actually `text/plain`. - The MIME type is redundant anyways. `StringContent` implicitly means `text/plain` by default until specified otherwise. - And the only place that used the `StringContent` path was wrong anyway, it was supposed to be doing `application/x-www-form-urlencoded`. Which `FormUrlEncodedContent` is for, and is now used in the relevant context.
bdach
force-pushed
the
fix-bad-mime-type
branch
from
a29de0a to
90a0989
Compare
|
the parameters are ignored when they're invalid so it has been a noop. also might as well just pass it as json and remove support for the other type... |
Sorry, I'm going to ask for clarification, as this is ambiguous to me. Are you saying that the lio endpoint in question supports json? And thus we can just send json in a similar shape as the form? |
|
apart of the oauth, I think they all support all parameter types (as long it's valid) and fwiw the same endpoint has been used with json for reindexing deleted scores recently |
|
oh and while at it maybe don't customize the request content if the post object is null... (either that or serialize an empty object) |
|
I was gonna still address the points above, but I guess now that this is merged I... won't? Should have marked as blocked I guess 🤷 |
|
Seemed like it would have been a follow-up change, oops. |
|
Alright, I'll do a round 2 then. |
Follow up from ppy#297 - Removed support for both `text/plain` and `application/x-www-form-urlencoded`, leaving only `application/json` - If the request is made with a null payload object, do not set `Content-Type`
As pointed out internally.
plain/textis exactly backwards; it's actuallytext/plain.StringContentimplicitly meanstext/plainby default until specified otherwise.StringContentpath was wrong anyway, it was supposed to be doingapplication/x-www-form-urlencoded. WhichFormUrlEncodedContentis for, and is now used in the relevant context.Mind you, all this seems to have absolutely no impact on anything whatsoever and be 100% academical, because as far as I can see, on local environment the web LIO endpoint just responds with 204 anyways, with or without this PR. I'd expect 415 if it didn't like anything above, so I'm wagering it just didn't care or check and all of this had an impact of exactly none whatsoever.