The library's multipart/form-data implementation uses custom logic to bypass the use of the filename*Content-Disposition parameter, which is RFC 6266's method of encoding non-ASCII filenames in multipart/form-data requests. This bypass was made in deference to an interpretation of RFC 7578 wherein the use of filename* is disallowed.
This PR removes the restriction by directly using System.Net.Http.MultipartFormDataContent.Add()'s filename* behavior.
Although pending discussion with the Base Common Library team is still needed to clarify best interoperability practices, this is a better current state because:
It aligns with the existing language type in System.Net.Http
The interpretation of the competing RFC is ambiguous; it appears it may not be making a statement about the filename* parameter itself, but rather on the use of the encoding scheme of the newer filename* in the older filename
Most importantly, it fixes the readily observable issue against the OpenAI V1 endpoint -- and still leaves the older filename intact for any unanticipated backwards compatibility issues with API gateways or other intermediaries
Fixes #72.
The library's
multipart/form-dataimplementation uses custom logic to bypass the use of thefilename*Content-Dispositionparameter, which is RFC 6266's method of encoding non-ASCII filenames inmultipart/form-datarequests. This bypass was made in deference to an interpretation of RFC 7578 wherein the use offilename*is disallowed.This PR removes the restriction by directly using
System.Net.Http.MultipartFormDataContent.Add()'sfilename*behavior.Although pending discussion with the Base Common Library team is still needed to clarify best interoperability practices, this is a better current state because:
System.Net.Httpfilename*parameter itself, but rather on the use of the encoding scheme of the newerfilename*in the olderfilenamefilenameintact for any unanticipated backwards compatibility issues with API gateways or other intermediaries