目次
Nekoxy2 で実装している内容。
参照 RFC7230 6.7
サーバー側からプロトコルの移行を指示する場合、426 Upgrade Required レスポンスを用いる
Upgrade ヘッダーは hop-by-hop ヘッダーであり、指定されたプロトコルに対応していない中継者による回送を防ぐために、Connection ヘッダーに upgrade を指定しなければならない
HTTP フォワードプロキシが介在する場合、単に通信を中継するだけでなく通信される内容も変化する。
もちろんプロキシの機能として HTTP メッセージの改変が行われる場合はあるが、それ以外の場合でも変化する部分はある。
GET /hoge HTTP/1.1GET 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 を送信すると正しく動作しないサーバーが非常に多い。
恐らくはリバースプロキシでのリライトルールあたりとの相性が悪いせいではないかと考えられる。