You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some tasks (e.g. automatic-speech-recognition) we are sending raw bytes in the HTTP request. On InferenceAPI, there is a "content-type-guess" logic to implicitly interpret the data that is sent. However, this logic can be flawed and moreover, the Inference Endpoints don't have this logic.
It currently possible to provide the Content-Type headers by providing a value when initializing the InferenceClient :
However this is not well documented + it doesn't feel correct to initialize a client with a specific content type (it would mean that all requests made with the client have to send the same content type).
Opening the issue here but not clear to me what we'd like to do. A few solutions could be:
(low hanging fruit) keep what we have but document how to set content-type headers in each method docstring
infer the content type header based on file extension (but don't work if raw bytes are passed to the method)
add a parameter? (but how would it work with auto-generation?)
Open to suggestions on this
The text was updated successfully, but these errors were encountered:
First reported by @freddyaboulton on slack (private).
For some tasks (e.g. automatic-speech-recognition) we are sending raw bytes in the HTTP request. On InferenceAPI, there is a "content-type-guess" logic to implicitly interpret the data that is sent. However, this logic can be flawed and moreover, the Inference Endpoints don't have this logic.
It currently possible to provide the
Content-Type
headers by providing a value when initializing theInferenceClient
:However this is not well documented + it doesn't feel correct to initialize a client with a specific content type (it would mean that all requests made with the client have to send the same content type).
Opening the issue here but not clear to me what we'd like to do. A few solutions could be:
Open to suggestions on this
The text was updated successfully, but these errors were encountered: