SDK: fix string field serialization for multipart/form-data requests

[SpecLad]

Django REST Framework ignores the Content-Type on request body parts, so it doesn't know that they are JSON-encoded. Instead, it just tries to decode each part as if it was an str()-encoded value.

Change the encoding to match the decoding. The only type this matters for is str, because json.dumps and str produce different encodings for str values.

Remove none_type from the list of encodable types since, to my knowledge, there's no way to encode a None value as a multipart/form-data part in a way that DRF will understand.

Motivation and context

This is a follow-up to #5058. Replaces #5240.

How has this been tested?

API unit tests.

Checklist

• I submit my changes into the develop branch
• I have added a description of my changes into CHANGELOG file
• [ ] I have updated the documentation accordingly
• [ ] I have added tests to cover my changes
• [ ] I have linked related issues (read github docs)
• [ ] I have increased versions of npm packages if it is necessary (cvat-canvas,
  cvat-core, cvat-data and cvat-ui)

License

• I submit my code changes under the same MIT License that covers the project.
  Feel free to contact the maintainers if that's a concern.

[SpecLad]

FWIW, I think we should eventually phase out support for multipart/form-data requests.

AFAICS, the only advantage this format has over JSON is that Django makes it easy to handle arbitrary-length file uploads (since it saves the incoming files in a temporary directory). But we already support TUS, which also lets clients upload such files.

On the other hand, multipart/form-data is massively limited in what data types it can encode, and tools can be inconsistent in how they handle field values that are not strings. Not to mention that supporting an extra content type means more required testing, and more opportunities for bugs.

[zhiltsov-max]

Does the exclusion of None mean SDK users will obtain errors when trying to send None values in POST requests?

[SpecLad]

Yes. But I don't think you can send None values as multipart/form-data anyway, so better to fail early.

[zhiltsov-max]

AFAICS, the only advantage this format has over JSON is that Django makes it easy to handle arbitrary-length file uploads (since it saves the incoming files in a temporary directory).

I may be wrong, by comparing to JSON, multipart/form-data should allow passing binary data with no extra encoding overhead, while in JSON we need to encode the data using escape sequences and text characters.

[SpecLad]

I may be wrong, by comparing to JSON, multipart/form-data should allow passing binary data with no extra encoding overhead, while in JSON we need to encode the data using escape sequences and text characters.

Yeah, fair point. Still, TUS also lets you do this, so we don't need multipart/form-data support.

[zhiltsov-max]

TUS also lets you do this, so we don't need multipart/form-data support.

Probably, we still have at least 1 use case when we need multipart/form-data - it is when we send multiple files in a single request during task data uploading (both Upload-Multiple and the legacy single request variants). Also, AFAIK requests and urllib automatically encode files as multipart requests.

[SpecLad]

Probably, we still have at least 1 use case when we need multipart/form-data - it is when we send multiple files in a single request during task data uploading (both Upload-Multiple and the legacy single request variants).

Yeah, it's true.

Perhaps we just need to be careful with the parameters that we accept alongside file uploads, and only use parameter types that can be transferred by simple serialization.

[zhiltsov-max]

Perhaps we just need to be careful with the parameters that we accept alongside file uploads, and only use parameter types that can be transferred by simple serialization.

It seems like the only working way now, actually. If we will split the parameters by requests and only send the required params (which is only the image_quality now) with client_files (or other files), it works. It doesn't look very attractive to me, but there is no better way found yet. Could you reflect this fact and the way to resolve in the documentation next to other API usage recommendations?

Upd.: I have an idea that for files, can we encode them into some reversible ASCII-based representation (e.g. base64) for transfer.