目次
Nekoxy2 で実装している内容。
参照 RFC7230 6.7
サーバー側からプロトコルの移行を指示する場合、426 Upgrade Required レスポンスを用いる
Upgrade ヘッダーは hop-by-hop ヘッダーであり、指定されたプロトコルに対応していない中継者による回送を防ぐために、Connection ヘッダーに upgrade
を指定しなければならない
HTTP フォワードプロキシが介在する場合、単に通信を中継するだけでなく通信される内容も変化する。
もちろんプロキシの機能として HTTP メッセージの改変が行われる場合はあるが、それ以外の場合でも変化する部分はある。
GET /hoge HTTP/1.1
GET http://example.com/hoge HTTP/1.1
いずれも HTTP の意味論的な変更ではなく、通信上の都合により変更が許されている部分である。
参照 RFC7230 5.3
method request-target HTTP-version
で構成される
GET / HTTP/1.1
型式名 | 例 | 用途 |
---|---|---|
origin-form | GET /where?q=now HTTP/1.1 |
最もよくある形式 |
absolute-form | GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 |
プロキシ向けリクエストはこの形式でなければならない |
authority-form | CONNECT www.example.com:80 HTTP/1.1 |
CONNECT メソッドでは必須。CONNECT メソッド限定。 |
asterisk-form | OPTIONS * HTTP/1.1 |
OPTIONS メソッドでは必須。OPTIONS メソッド限定。リソースのワイルドカード的に用いられる。 |
このうち、absolute-form は原則プロキシ向けのリクエストにのみ用いられるが、サーバーは absolute-form を受容可能でなければならない。
理由は将来の HTTP バージョンでは全て absolute-form への移行を可能にするためとされている。
実際に HTTP/2 では、リクエストラインに相当する機能は擬似ヘッダーフィールドに変更されているものの、absolute-form に相当するだけの情報を持つようになっている。
しかし実際に absolute-form を送信すると正しく動作しないサーバーが非常に多い。
恐らくはリバースプロキシでのリライトルールあたりとの相性が悪いせいではないかと考えられる。
目次
参照 RFC7230 4, 3.3.1
コンポーネント凝集性の原則に閉鎖性共通の原則(CCP)もあるが、どちらも概念としては同じである。
モジュールはたったひとつのアクターに対して責務を負うべきである。
(Clean Architecture / Robert C.Martin)
クラスレベルでは、単一責任の原則(Single Responsibility Principle)。
コンポーネントレベルでは、閉鎖性共通の原則(Common Closure Principle)。
SOLID 原則は知っていても、どのようにクラスを定義するか、コンポーネントを分割するか、つまりどこに境界線を引くべきかを悩むことは多い。
単一責任、変更する理由は一つだけであるべきと言われても、その「責任」がふわっとしていて定まらないなんてことはよくある。
Clean Architecture の上記部分を読んでようやく、「責任」には当然「対象」が存在する事に気付いた。
つまりクラスにしろコンポーネントにしろ、必ず利用するアクターは存在する。
アクターとは、同じ変更理由を持ったユーザー等の集まりだ。
となると、モジュールが複数のアクターに対して責任を持ってしまうと複数の変更理由が発生する可能性が出てくる。
なので、モジュールが単一のアクターに対して責任を持つように境界線を引くべきなのだ。
一見よく似た処理や画面だったとしても、アクターが異なれば異なる変更理由で変更が入ることがあるため、分けた方が良い。
複数のアクターが全く同じように使う共通的なモジュールもあるだろうが、それは恐らくより抽象化されたアクター(汎化アクター)がそれに対応するのだろう。
目次
参照 RFC7230 6
Connection: keep-alive
リクエストヘッダーにより TCP コネクションを閉じず再利用する持続的接続 (Persistent Connection) ができるようになったConnection: keep-alive
は必要ない
自作プロキシ (Nekoxy2) の WebSocket (RFC6455) 対応にあたっての私なりの理解をまとめました。
WebSocket 自体はかなり単純で、TCP 上で投げっぱなし全二重通信をする方法と、HTTP/1.1 からのプロトコル アップグレード方法 (WebSocket の開始方法) が定義されているだけです。
実際に何を通信するかはサブプロトコル等のアプリケーション側にお任せとなります。
WebSocket over HTTP/2 (RFC8441) では、この内アップグレード方法が HTTP/2 向けに新しく定義されただけで、通信方法は同一となります。
※ 詳細は HTTP/2 理解メモ 参照。
注意点としては、接続・切断については到達保証がありますが、それ以外のメッセージには到達保証がないため、必要に応じてアプリケーション等で実装する必要があります。
また HTTP が利用するコネクションを再利用する形となるため、経路上に非対応の透過プロキシなどが存在する場合に通信が失敗する可能性があります。