Headers, Caching, and Cookies: Oh my!

I had to pound my fists on the table again when the topic of cookies, caching, headers, and all sorts of jargon popped up when talking about the tech of webapps.  Webapps, like online shopping cart apps, are one of those concepts that are simple on paper but can easily become convoluted, especially when terms get swapped around or poorly defined.  So I'm running down the list based on experience.

Since this is pragmatist approach, not theoretical smoke & mirrors, I'll freely refer to common software implementations of the concepts, including Apache HTTPD, JBoss/Wildfly, and the all powerful cURL.

Back to Terms & Definitions

Back to basics.  Web services are almost entirely based on a protocol that was purposely designed to NOT maintain the state of any communication.  aka. HTTP.  "It is a generic, stateless, protocol"[1].   Technologists have, since the original inception, extended and modified HTTP to enabled stateful mechanisms. :sigh:  Those modifications include:

• Stickiness - "stickiness" is nothing more than than an antonym for "load balancing".  In other words, you actually _want_ your web client to be serviced by a particular server (affinity).  Implementations of stickiness are often done with HTTP Headers!  :gasp:  Not especially what they were intended for (see Web definition) but implementations in Header include:
• Cookie - statefulness; https://tools.ietf.org/html/rfc6265
• Sessions / SESSIONID (JSESSIONID/PHPSESSIONID) - more statefulness
• jvmRoute - mod_jk / mod_proxy[2]  

• Authenticated Sessions - obviously not the same as a bare bones web session; anyone who tells you that all you need is to put everything, including sessions, behind HTTPS is full of security blackmail.  TLS/SSL over HTTP has nothing to do with authenticating the session; it may (though not always) be authenticating the communication from client to server -- but that is it!  An Authenticated Session is not achieved by HTTPS.

• Caches - not to be confused with Cookies; client-side (web browser) cache[3] -- often mislabelled as "cookies"; server-side (web site) cache -- mod_cache
• Cache everything!  Actual web services payload may vary.  Based on data from one of the largest content delivery services for the Web, Akamai, the top 3 culprits slowing down web payloads are: 1) images, 2) images, and 3) images.

• Load balancing - only makes sense when talking about volume (throughput); has no bounded direct link to latency!  You can have a well balanced load that includes a session that is simply slllllooooww (latent).  That in no way means the lb (mod_proxy, mod_cluster for Apache HTTPD) is broken but could very well mean a stuck thread on the backend JBoss or DB.

References

[1] https://tools.ietf.org/html/rfc2616. versus  https://tools.ietf.org/html/rfc6265
[2] http://tomcat.apache.org/connectors-doc/reference/workers.html
[3] pg. 108 / Section 14.9 Cache-Control, https://tools.ietf.org/html/rfc2616#section-14.9