Preliminary Remarks

Normally, HTTP authentication works as described under https://tools.ietf.org/html/rfc2617. In case of a Basic Authentication, the procedure is as follows.

• The client sends a request without login and password.

• The server recognizes that the requested URL requires a login and therefore returns HTTP status 401 to the client.

• When the server expects Basic Authentication, it sends a response header. WWW-Authenticate: Basic realm="RealmName"

• The client decides if he knows a username and password for this URL from a recent request.

• If the client does not have login data, it usually asks the user to enter those in the login dialogue.

• The client resends the request with the HTTP header. Authorization: Basic d2lraTpwZWRpYQ==

• The value d2lraTpwZWRpYQ== is just an example Base64 encoding of the value wiki:pedia (i.e. the username wiki and password pedia). For details on the Base64 encoding, see the documentation for the Admin Console of the Integration Server.

• The server checks the login information. If he accepts them, he grants access.

• If it does not accept the login, the server either sends status 401 again or status 403.

• Status 403 means that the client has sent an authorization header but the user is not authorized or that the requested operation is prohibited for all users.

The access thus consists of two requests, the first of which is done without a login and only the second is done with login data (after the server replies with status 401). This is very inefficient for a POST request because several kilobytes of data are possibly uploaded without benefit on the first request.

The Technical Process of the Preemptive Authentication

In this case, the client simply sends the HTTP header Authorization on the first request. Especially when data is uploaded to a web service via POST, this saves half of the upload volume and time. An HTTP/HTTPS server that allows Basic Authentication will usually accept the preemptive variant as well. For other authentication methods, e.g. NTLM, the first request is not dispensable, because the server sends a key/hash/code in its first response, which the client then has to use in some way to create the second request.

If the Server Supports Preemptive Authentication Only

If the server requires that the client already sends the Authorization HTTP header on the first request, communication will not be established unless the client is configured accordingly. The client will then send the first request without login, but the server does not respond with status 401, but immediately with 403. However, since the client does not receive a challenge through status 401, it will not send an Authorization HTTP header with the next request either. A successful communication will not be established that way.

Servers that only allow preemptive authentication are certainly the absolute exception. However, if such an error occurs (status 403) when accessing an HTTP server, one must consider the possibility that a preemptive login is expected. But that's not the only possible cause for a response status 403. See https://en.wikipedia.org/wiki/HTTP_403.

Does Lobster_data Support Preemptive Authentication?

This question is especially relevant when Lobster_data acts as a client. HTTP headers in an HTTP Response Route or time-driven Input Agents with data source HTTP are inserted as follows. The BASE64 value (d2lraTpwZWRpYQ==) must first be generated out of <username>:<password> (so here from wiki:pedia, see preliminary remarks above). Then it is inserted in the dialogue, as shown in the screenshot above.

Entering username and password in the usual fields of Response Routes or Input Agents will then be irrelevant because it will never be used.