Requests of all types go through some common processes before being handed off to the transaction specific controller.
Our application converts all request parameters to UTF-8.
Before converting, the source encoding must be known. First, the Content-type header, similar to the following, is searched for a valid charset parameter.
Content-type: application/x-www-form-urlencoded; charset=utf-8
Many browsers, however, do not properly indicate the character encoding of POST payloads, so if your integration uses client-side requests — HTML forms or JS — the encoding will not likely be specified. That’s ok — our detection process works very well.
Encodings are detected in the following order, and the first encoding matched is used. Detection depends mostly on validation of byte sequences, so many times data of one encoding can appear valid as another; for this reason, order is very important.
The username and password Control Parameters are authenticated against our authentication system. In addition, username is used to identify the user’s eQuest account and profile.
The remaining Control Parameters are validated.
Some small modifications are done to the given Job Parameters before being validated. Modifications include:
Mostly, this is where we implement conversions for backwards compatibility.