上映posterは、最初の封筒に入らなかった。
イトが、自分で抜いた。
新しい端末で案内pageを開くpreviewまで、あと八秒。
Web server受付には、第12話の最後に届いたrequestが光っている。
GET /screenings/finale受付の棚には、四つの材料があった。
HTML。
CSS。
JavaScript。
上映posterのimage。
posterは、四色の中でいちばん大きく、いちばん目を引いた。これを先に返せば、真っ白な画面を一瞬で変えられる。
イトはposter cardを、最初のresponse envelopeへ入れた。
イト
pageを見たいんだから、まず一番目立つ絵を返そう
ユイ
request targetは、posterのURLでしょうか
ピコ
何がほしいrequestか、封筒をもう一度見よう
残り七秒。
GETは、targetのrepresentationを求める
requestにはmethodとtargetがある。
今回のmethodはGET。
targetは/screenings/finaleというpage resourceだ。
RFC 9110のGETは、target resourceのcurrent selected representationを転送するよう求めるmethodとして定められている。
resourceそのものを箱へ入れて運ぶのではない。
通信できる形で、そのresourceの状態を表すrepresentationを返す。
一つのresourceに複数のrepresentationがあり、条件に応じて選ばれることもある。
このfictional siteでは、/screenings/finaleのnavigationへHTML representationを返す契約にしている。
poster imageには、別のtargetがある。
GET /media/finale-posterposterをpage targetのresponseへそのまま入れれば、browserはimageを受け取れる。
けれど、heading、上映時刻、字幕button、posterを置く場所を示すpage structureは届かない。
マコト
目立つ材料と、いま頼まれたresourceは別だね
イト
pageのrequestへposterを返すと、posterを見るだけでpageにはならないのか
残り六秒。
HTMLには、次のrequestの手がかりがある
HTML cardを開くと、pageのstructureと材料の場所が書かれていた。
<link rel="stylesheet" href="/styles/screening.css">
<h1>最終話上映</h1>
<button id="caption-toggle">字幕を表示</button>
<img src="/media/finale-poster" alt="最終話の上映poster">
<script src="/scripts/captions.js" defer></script>HTMLは、CSSやimageそのものを必ずすべて含むわけではない。
このpageでは、hrefやsrcに別resourceのURLがある。
browserがdocumentを処理すると、必要なresourceをそれぞれ取りに行く。
HTML Living Standardのstylesheet linkにはstylesheet resourceの取得と適用、script elementには外部scriptの取得、imageにはimgとimage sourceの処理が定められている。
ただし、すべてのsiteが同じfile分割を使うわけではない。
CSSやJavaScriptをHTML内へ入れるpageも、いくつかのfileをまとめるsiteも、HTMLをその場で生成するWeb applicationもある。
ここで追うのは、このpageが選んだ「HTMLから別resourceを参照する」設計だ。
三つの最初の封筒
残り五秒。
ピコが、最初のnavigation responseへ入れられる三枚の札を並べた。
- posterだけ
- 独自の全部入り箱
- targetに対応するHTML
一枚目なら、最初から派手なposterが見える。けれどpage structureも字幕buttonも届かない。
二枚目なら、HTML、CSS、JavaScript、imageを独自形式の一箱へ入れられる。けれど、このpageを開くbrowserは、その箱をHTML documentとして処理する約束を持っていない。
三枚目なら、最初の瞬間はplainなheadingやbuttonだけになる。posterは一呼吸遅れる。その代わり、browserはHTMLを読み、次に必要なtargetを自分で見つけられる。
poster cardの色が、イトの指を照らしていた。
最終話のpageで、最初に見てほしい絵だ。
それを封筒から抜けば、previewの最初は地味になる。
ピコ
どのresourceを返す？
ユイ
目立つ順ではなく、requestとresponseがつながる順を選ぶ場面ですね
イトは、poster cardを最初のenvelopeから抜いた。
「posterは、posterのrequestへ返す」
image shelfへ戻し、代わりにHTML cardを入れた。
最初にstructure、次に三つのrequest
残り三秒。
Web serverがHTML responseを返す。
新端末のbrowserに、まだ色のないstructureが現れた。
最終話上映
字幕を表示
posterの場所は空いている。
その直後、HTML内のURLから三つのrequestが受付へ届いた。
GET /styles/screening.css
GET /scripts/captions.js
GET /media/finale-posterイトは、targetを一つずつ照合する。
CSS requestへstylesheet。
JavaScript requestへ字幕controlのscript。
image requestへ、さっき棚へ戻したposter。
Web serverはHTMLだけを返す名前ではない。
このsiteでは、request targetに応じてHTML、CSS、JavaScript、imageなどのresource representationを返す。
保存済みfileを返すこともあれば、別の処理と連携してresponseを生成することもある。「Web serverなら必ず棚のstatic fileだけ」という意味ではない。
残り一秒。
CSSが届き、headingとbuttonの見た目が整う。
JavaScriptが届き、字幕buttonの反応がつながる。
最後にposterが空いたframeへはまった。
posterを遅らせて、pageを完成させた
preview開始の光が点いた。
最初の一瞬、画面にあったのはheading、案内文、buttonのstructureだけだった。
そのあと、色と余白が重なる。
字幕buttonが動く。
最後にposterが現れる。
イトが最初のenvelopeへposterを残していたら、派手な一枚絵は見えただろう。
けれど、pageとして必要なheadingも、時刻も、字幕controlもなかった。
posterを遅らせたことで、browserはHTMLから材料の場所を知り、正しいtargetへrequestを送れた。
最初のresponseだけでpageの全仕事が終わるとは限らない。
page targetへHTML
HTMLから別resourceのURLを発見
resourceごとにrequest
Web serverがtarget別にresponse
browserがpageへ反映
イトは、完成したpageより、受付の記録を見た。
CSSとJavaScriptのresponseはすぐに届いている。
poster imageだけ、長いrailを走っていた。
同じposterを、次の端末も、その次の端末も遠い棚へ取りに行く。
HTMLを最初に返す順番は直せた。
でも、大きなimageが遠くから届く距離は残った。
「このposterだけ、近くの棚にcopyを置けないのかな」
次回：近くの分室はなぜ速い？
Web serverは、page targetへHTMLを返し、そこから届いたresource requestへCSS、JavaScript、imageを返した。
次に残ったのは、同じ大きなfileを遠いoriginから何度も運ぶ時間だ。
利用者の近くにcopyを置き、近い場所から返す仕組みとは何か。
次回、ピコルート第14話。
遠いposterを、近くの分室から返す。
画面のむこう側をもっと知る
物語で見たWeb server、HTML、static file、resource requestを図で整理するなら、Webサーバーとはで確かめられます。