第38話で、standby program pageは会場screenへ戻った。
けれど、まだ一つ仕事が残っている。
離れた三つのprojectorへ、同じpageを開く案内札を送る。
browserから、長い札が出てきた。
https://festival.example/program?view=standby#screen
イトは、札を両手で持ち上げた。
「こんなに長いと、途中で間違える」
projectorの受付が閉じるまで、四十五秒。
イトは、最初の/より後ろをはさみで切った。
残したのは、これだけだ。
https://festival.example/
「同じsiteなら、入口まで分かれば中で見つけてくれるはず」
イトは短い札を三つのprojectorへ送った。
同じsiteには着いた。でも、違うpageだった
三つのscreenが一斉に開く。
表示されたのは、星見フィルム祭のlobby pageだった。
大きな星の印はある。
site名も合っている。
でも、今夜のprogramも、standby pageも、会場用screen sectionもない。
destination origin: reached requested resource: lobby
残り、三十七秒。
イトは、切り落とした長い札を見た。
「同じ建物に着いたのに、欲しいpageじゃない」
ピコは、lobbyを閉じなかった。
代わりに、切れた札を五色のtrayへ置いた。
イト
URLって、siteの場所を示す住所じゃないの？
ピコ
siteの入口だけではなく、その中のtarget resourceまで識別できる
イト
後ろを短くしたら、同じURLの短縮版じゃなくて別のtargetになった？
ピコ
このfixtureではそうだよ。componentを外すと意味が変わる場合がある
URLは、一枚の札に見えるURI
URIは、resourceを識別するcompactな文字列だ。
URLは、その中でもaccessする仕組みや場所を通してresourceを識別する呼び方として使われてきた。
Webでは、browserのaddress barに入れる文字列をURLと呼ぶことが多い。
この物語では、https schemeを持つWeb URLを分けて見る。
RFC 3986のgeneric syntaxでは、URIは次のcomponentに分かれる。
scheme authority path query fragment
全部がすべてのURIに必ずあるわけではない。
schemeごとの規則もある。
それでも、区切り記号を先に見れば、長い札を一文字ずつ暗記せずに読める。
一枚目：schemeは、残りの解釈を決める
最初のtrayに、httpsが入った。
その後ろの:は、scheme名の終わりだ。
schemeは、そのURIをどの仕様で解釈するかを示す。
今回のhttps URLでは、secured HTTP communicationを使ってauthorityへaccessする。
RFC 9110は、https URIについて、相手serverのidentityをauthorityと照合し、保護されたconnectionでHTTPを行うことを定めている。
ただし、httpsだからpageの内容が正しい、商品が安全、相手を信用してよい、とまでは言えない。
守るのは、正しく確立されたconnectionとauthorityの関係だ。
内容の判断まで代わりにはしない。
二枚目：authorityの中からhostを見る
次は、//の後ろだ。
festival.example
generic syntaxでauthorityは//から始まり、次の/、?、#、または文字列の終わりまで続く。
authorityには、hostとoptional portが入る。
今回のauthorityにはportの明記がなく、hostはfestival.exampleだ。
hostはdomain nameの形とは限らず、IP address literal等の場合もある。
この物語のhostは、学習用に予約された.exampleを使う架空名だ。
HTTP(S)では、authorityがどのoriginへauthoritativeなresponseを求めるかを決める大切な境界になる。
だから、pathの中に知っている言葉があっても、authority / hostが違えば同じoriginとは限らない。
でも、hostが同じなら、いつも同じpageになるわけでもない。
イトが送った短い札はhostまで合っていた。
それでlobbyには着いた。
三枚目：pathは、origin内のtargetを分ける
三つ目のtrayには、/programが入った。
pathはhierarchicalな形でresourceを識別するcomponentだ。
/でsegmentが分かれて見える。
しかし、serverのdisk上に同じ名前のfolderがあるとは限らない。
Web applicationがrouteとして解釈し、databaseやprogramからresponseを作ることもある。
https://festival.example/
https://festival.example/program
二つはauthority / hostが同じだ。
それでもpathが違うため、このfixtureではlobbyとprogramという別targetになる。
「建物は同じ。でも、入口のhallと上映programは同じresourceじゃない」
イトは、切り落とした/programをhostの右へ戻した。
四枚目：queryは、pathと一緒にtargetを分ける
四つ目は、?の後ろだ。
view=standby
queryは、pathとともにscheme / authorityの範囲内でresourceを識別するnon-hierarchicalなdataだ。
名前と値に見える書き方は多い。
けれど、その意味はservice側の仕様で決まる。
検索条件、表示mode、page番号、version選択などに使われることがある。
trackingだけに使われるとは限らない。
「長いから不要」と一律に削ることもできない。
このfixtureでは、queryなしの/programは修理中のmain representationを指す。
?view=standbyを付けると、承認済みstandby representationを選ぶ。
queryを落とせば、同じpageを短く表示するのではなく、違う結果になった。
五枚目：fragmentは、serverへ運ぶ札ではない
最後は、#の後ろにあるscreenだ。
fragmentは、resource内のsecondary resourceを間接的に識別する。
今回なら、返ってきたprogram pageの中にある会場screen sectionを指す。
重要な違いがある。
HTTP clientがtarget URIを作るとき、fragment componentは除かれる。
RFC 9110も、fragmentはclient-side processingのために残し、HTTP target URIから外すと明記している。
browserはscheme、authority、path、queryからrequest targetを作る。
representationが返ったあと、#screenを使ってpage内の対象へ進む。
fragmentを変えたときに新しいnetwork requestが必ず発生する、という意味ではない。
pageやbrowserの状態で動きは変わる。
WHATWG URL Standardでも、Web platformのURLをscheme、host、port、path、query、fragmentへ分けてparse / serializeする。
イトに残った三つの案内札
projectorの受付が鳴った。
残り、二十一秒。
五色のtrayの前に、三つの札が開く。
A 短いhostだけをもう一度送る
https://festival.example/
lobbyへ着くことは、もう確かめた。
でもprogram resourceではない。
B pathまで戻し、queryとfragmentは短縮する
https://festival.example/program
program targetへ近づく。
けれど、このfixtureではmain representationがまだ修理中で、会場screen sectionも指定しない。
C 確認済みのfull URLをcomponentどおり戻す
https://festival.example/program?view=standby#screen
standby representationを求め、返ったpage内のscreen sectionへ進める。
ピコは、五つのtrayを照らしただけだった。
「短い方がきれい？」
イトは、lobbyが映った三つのscreenを見る。
切り落としたpath、query、fragmentを見る。
「長さじゃない。どのtargetを開くかを変えない札を送る」
イトはCを選んだ。
自分の手で、scheme、authority、path、queryを一列へつなぐ。
fragmentの札だけは、browser側のbookmark railへ置いた。
イトがfull URLを三つのprojectorへ送り直した。
serverへ四枚、browserに一枚
最初のprojectorがURLを受け取る。
browserはhttps schemeを読む。
authorityのfestival.exampleから、対象originへのaccessを始める。
HTTP requestには、/program?view=standbyというtargetが入る。
#screenは入らない。
Web originから、standby programのrepresentationが戻る。
browserはpageを開き、手元に残したfragmentでscreen sectionへ進んだ。
二つ目のprojectorも、同じsectionを映す。
三つ目も、lobbyを通り過ぎて会場用screenへ着いた。
standby program: received screen section: selected locally
残り、七秒。
三つのscreenに、同じ星のprogramがそろった。
イトは、短く切った札を捨てなかった。
hostだけの札にはlobbyの小さなcardを添える。
pathまでの札には、修理中main pageの琥珀cardを添える。
full URLには、standby screenの青いcardを添える。
同じhostでも、三つは同じ結果ではなかった。
はさみではなく、区切り線を残す
受付時計が止まった。
イトは、URLを短くするはさみを箱へ戻した。
代わりに、一枚の長い札へ五本の色境界を残した。
scheme。
authority。
path。
query。
fragment。
文字列は、短くなっていない。
けれど、どこを変えると何が変わるかは見える。
三つのprojectorはstandby screenを映し続ける。
その下には、切り落としたhost-only札と、lobbyの小さなcardが残っていた。
次回：札の先で、pageを作るのは誰？
正しいURLを通ったrepresentationが、browser工房へ運ばれた。
中には、HTMLの骨組み、CSSの色布、JavaScriptの歯車、画像の箱が入っている。
イトは、材料の山と完成したscreenを見比べた。
「serverからpageが完成したまま届くわけじゃないの？」
browser工房の奥で、組立台が動き出した。
次回、ピコルート第40話。
ブラウザは何をしている？ Webページ工房へ入ろう
URL componentを図で確かめる
scheme、host、path、query、fragmentの境界と読み方を一枚で整理するなら、URLとは何かでcomponent図を確かめられます。