Assume given a third-party API not under the developer's control which explicitly only responds to Content-Type: application/json and which returns a 415 - Unsupported media type status code for all other content types.
Actual result
It is impossible to succesfully make a request to such an API using can-ajax.
The library tries to protect the user from executing a CORS preflight request and will in all cases where it deems the HTTP method allows for a 'simple CORS request', override the Content-Type header with application/x-www-form-urlencoded content type.
There is no way to override this and implementing such a request with can-ajax is a complete no-go.
It is necessary to drop the abstraction layer and work directly with the raw XmlHttpRequest or fetch browser APIs.
Expected result / Mitigation
There is an override escape-hatch possible for the above scenario:
if the developer specifies an explicit contentType, then that means 'hands off' and it gets used without any magic auto-assist.
Assume given a third-party API not under the developer's control which explicitly only responds to
Content-Type: application/jsonand which returns a415 - Unsupported media typestatus code for all other content types.Actual result
It is impossible to succesfully make a request to such an API using
can-ajax.The library tries to protect the user from executing a CORS preflight request and will in all cases where it deems the HTTP method allows for a 'simple CORS request', override the
Content-Typeheader withapplication/x-www-form-urlencodedcontent type.There is no way to override this and implementing such a request with
can-ajaxis a complete no-go.It is necessary to drop the abstraction layer and work directly with the raw
XmlHttpRequestorfetchbrowser APIs.Expected result / Mitigation
There is an override escape-hatch possible for the above scenario:
if the developer specifies an explicit
contentType, then that means 'hands off' and it gets used without any magic auto-assist.