HTTPはステートレスであるため、ウェブブラウザを実行するクライアントコンピュータは、HTTP GETリクエストまたはPOSTリクエストごとにTCPネットワークコネクションをウェブサーバに対して確立しなければならない。従ってウェブサーバは、単一のHTTP GETまたはPOSTオペレーションより長い間、確立したTCPネットワークコネクションを使用することはできない。セッション管理は、ウェブ開発者がステートレスなHTTPプロトコルをセッションステートに対応させるために使う技術である。たとえば、一度ウェブサーバに承認されたら、次のHTTPリクエスト (GETまたはPOST) でサーバから再びアカウントとパスワードを求められることは起こるべきではない。これを達成するために使用される方法の議論については、HTTPクッキーとセッションIDを参照のこと。複数のウェブサーバがセッション状態を共有しなければならない状況 (クラスタ環境で一般的である) では、セッション情報はウェブサーバソフトウェアを実行しているクラスタノード間で共有しなければならない。クラスタのノード間でセッション状態を共有する方法には、マスタノードへのセッション情報のマルチキャスト (このテクニックの一例についてはJGroupsを参照のこと)、分散共有メモリまたはメモリ仮想化を用いたパートナーノードとのセッション情報の共有、ネットワークソケットを用いたノード間でのセッション情報の共有、分散ファイルシステムまたはグローバルファイルシステム等の共有ファイルシステム上へのセッション情報の保存、またはセッション情報のクラスタ外のデータベースへの保存、等がある。トランザクションの否認不可性に必要ではなく、かつ遵法監査の対象 (遵法監査を要する次の2つの米国の法律の例については、w:Health Insurance Portability and Accountability Actとw:Sarbanes-Oxley Actを参照) となっていない、トランジェントな揮発性データだと見なされるセッション情報には、どのような保存方法も使用できる。しかし、セッション情報が遵法監査の対象となる場合、セッションの保存、レプリケーション、そしてクラスタリングに使用する方法を慎重に検討すべきである。サービス指向アーキテクチャでは、XMLメッセージで構築されたSOAPメッセージをコンシューマアプリケーションで使用してウェブサーバにセッションを作成させることができる。
セッション管理はウェブブラウザで特に有用で、開いてあるページと設定をすべて保存して後日復元することができる。また、システムまたはアプリケーションのクラッシュからの復旧を支援するため、ページと設定を次回起動時に復元することがある。Google Chrome、Mozilla Firefox、Internet Explorer、OmniWeb、そしてOperaは、セッション管理に対応したウェブブラウザの例である。セッション管理にはクッキーを応用することが多い。
デスクトップセッションマネージャは、デスクトップセッションの保存と復元を行うことができるプログラムである。デスクトップセッションとは、現在実行中のすべてのウインドウとその内容のことである。Linuxベースのシステムでは、セッション管理はXセッションマネージャによって提供される。マイクロソフトWindowsのシステムでは、セッション管理はセッションマネージャサブシステム (smss.exe) によって提供されるが、ユーザセッション機能はtwinsplay等のサードパーティ製のアプリケーションで拡張することができる。
ヒューマンマシンインタラクションにおいて、セッション管理とは、コンピュータシステムとの対話セッション全体でユーザの活動を追跡するプロセスのことである。デスクトップ環境での典型的なセッション管理内容には、開いてあるアプリケーションや各アプリケーションが開いている文書を記録し、ユーザがログアウトして再ログインした際に同一のステートを復元できるようにすること等がある。ウェブサイトの場合、セッション管理はセッションが期限切れとなったユーザ (つまり、ユーザが活動せずに一定時間が経過した場合) に再ログインを要求するために使用される場合がある。HTTPリクエスト間でサーバ側に情報を保存するのにも使用される。
セッショントークンは、現在の対話セッションを識別するためにサーバが生成してクライアントに送信する一意の識別子である。クライアントは通常、トークンをHTTPクッキーとして保存して送信し、そして／またはGETクエリまたはPOSTクエリのパラメタとしてトークンを送信する。セッショントークンを使うのは、クライアント側で扱う情報が識別子だけで済む、あるいはすべてのセッションデータがその識別子に関連付けられてサーバ上に保存される (通常データベースに保存され、クライアントはデータベースに直接アクセスすることはできない) ためである。プログラミング言語によるHTTPクッキーの命名例には、JSESSIONID (JSP)、PHPSESSID (PHP)、CGISESSID (CGI)、そしてASPSESSIONID (ASP) 等がある。
サーバサイドセッションは扱いやすく効率的だが、負荷分散／高可用性システムが絡むと困難になる恐れがあり、また、ストレージを持たない組み込みシステムの一部では全く使用できない。負荷分散の問題は、共有ストレージの使用またはクライアントごとに1台のクラスタ内サーバとピアリングを結ばせることで解決できるが、システムの効率性と負荷の配分が損なわれる恐れがある。大容量ストレージを持たないシステムでは、サーバサイドセッションを使う際、セッションデータの保存用にRAMを確保する方法がある。この方法は、クライアント数が限られているサーバに適用できる (クライアントへの同時アクセスが稀であるか許可されていないルータやアクセスポイント等)。
システィーナ礼拝堂の内部壁面は三層に大別できる。下層は金銀の布が描かれたフレスコ画である。中層には互いを補完しあう「モーセの生涯の物語」と「キリストの生涯の物語」のフレスコ画がある。これらのフレスコ画は1480年にローマ教皇シクストゥス4世が依頼したもので、ギルランダイオ、ボッティチェッリ、ペルジーノ、ロッセッリ (en:Cosimo Roselli) らが、それぞれが率いていた工房の弟子たちとともに制作に当たった。おそらく当時すでにローマにあって、システィーナ礼拝堂内部装飾の責任者になっていたと考えられているペルジーノのもとに集められた当時のフィレンツェを代表する画家たちは、1480年10月27日にフィレンツェを発ってローマへと向かい、1481年の初春から壁画制作を開始している。フィレンツェの画家たちがシスティーナ礼拝堂の内部装飾に任命された背景には、当時シクストゥス4世と仲違いしていた、フィレンツェの支配者ロレンツォ・デ・メディチとの関係修復という意味合いもあった。上層はさらに上下に二分割できる。下部には歴代ローマ教皇の肖像が等身大で描かれている。上部のルネットにはミケランジェロの天井画の一部として、キリストの祖先とされる歴史上の人物たちが描かれている。ミケランジェロがローマ教皇ユリウス2世の命でシスティーナ礼拝堂天井画を描いたのは1508年から1512年にかけてである。この天井画には『創世記』のエピソードから「天地創造」、「アダムとイヴ」、「失楽園」など9点のフレスコ画が描かれている。円天井を支える三角形のペンデンティヴには、神が救世主キリストを遣わすことを預言した『旧約聖書』の7人の預言者と古代の巫女（シビュラ）が描かれている。1515年に、ローマ教皇レオ10世の命で、ラファエロが礼拝堂壁面最下層を飾る10点のタペストリをデザインした。当時のラファエロは25歳にしてフィレンツェではすでに多くの富裕なパトロンを持つ有力な芸術家だった。そしてラファエロは野心ある若者であり、ローマ教皇をパトロンに持つという栄誉を希求していた。ローマ教皇に気に入られ、活気溢れるローマに魅せられたラファエロは、その後の生涯をローマで送ることになる。ラファエロはこのシスティーナ礼拝堂のタペストリ制作依頼を、自身の作品とミケランジェロの作品とを比較する絶好の機会だと見なしていた。またラファエロにタペストリ制作を命じたレオ10世にも、前任のローマ教皇ユリウス2世がミケランジェロに描かせた天井画への対抗心があったと考えられている。ミケランジェロがタペストリのモチーフとしたのは『使徒行伝』で、1515年半ばからデザインの制作が開始された。織り上げるためにブリュッセルに送られたタペストリのデザインは非常に大規模なもので、ピーテル・ファン・アールストの工房で4年間をかけて完成している。