Skip to content

Instantly share code, notes, and snippets.

@aappddeevv
Last active August 29, 2015 14:08
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save aappddeevv/418b22600ffe5adf2892 to your computer and use it in GitHub Desktop.
Save aappddeevv/418b22600ffe5adf2892 to your computer and use it in GitHub Desktop.
Asynchronous client behavior is tricky to do well when working with http

It is difficult to create a truly asynchronous http client. Generally, programmers will use an async client library like asynchttpclient to help them create their client. If the server requires authentication, it most likely has a method to avoid reauthentication using credentials because reauthentication with each request is costly. However, the presence of "state" like information in a stateless protocol introduces substantial complexity especially when the workload cannot be anticipated. A server may also create a reauthentication mechanism to help control the exposure of authentication credentials with each http request.

If authentication workload reduction methods are used by the server, they most likely require the use of state that must be maintained by the client, often sometype of time-limited token. If the token has time limits, it must be renewed periodically. A renewal request takes time and may introduce request failure because the renewal has not completed prior to other requests being issued. Regardless of whether you run a timer that renews the token or you renew the token when an authentication failure is first encountered, you have situations where a request may need to block until the token is retrieved. While the blocking may occur on a communication thread, versus your main application thread, this blocking may not be avoidable if you wish to provide automatic authentication behavior. Applications that must explicitly deal with authentication in addition to asynchrony and their application specific processing directly become complex quickly.

Other authentication methods may make more sense, for example, encrypting a new authentication header that can be easily decrypted by the server and does not require more costly authentication with each request. However, this approach may not be appropriate for all environments and application scenarios.

If you do have a session token that must be returned with each request and the session token has an automatic expiration period (that is potentially unknown to the application), then at some point in your client, you will need to issue a re-authentication request. During the re-authentication request, any requests sent to the server will fail unless they are sequenced after the re-authentication request. If re-authentication fails,the sequenced requests should also fail. You could also configure other automatic retry behavior. Sequencing the request on the returned value of the re-authentication request may imply that additional code is needed at the right level of interception to perform the sequencing if the client wishes to transparently provide this capability.

OWASP has provided some good material on session management.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment