3.3. Request Processing

Requests of all types go through some common processes before being handed off to the transaction specific controller.

3.3.1 Encoding Detection/Conversion

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.

• UTF-8
• UTF-16
• Windows-1252
• ISO-8859-1

Once the source encoding is detected, the data is converted to UTF-8 — if it isn’t already. Transliteration is used to minimize data loss.

3.3.2 Authentication

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.

3.3.3 Validation of Control Parameters

The remaining Control Parameters are validated.

3.3.4 Translation of Job Parameters

Some small modifications are done to the given Job Parameters before being validated. Modifications include:

• Ensuring uppercase of some values.
• Converting deprecated values.

Mostly, this is where we implement conversions for backwards compatibility.