タグ

ブックマーク / asnokaze.hatenablog.com (9)

  • HTTP/2 Connection Prefaceの理由と経緯 - ASnoKaze blog

    HTTP/2 Connection Prefaceとは HTTP/2では通信の最初に「コネクションプリフェイス(Connection Preface)」というメッセージを送信します。 クライアント側は「クライアントコネクションプリフェイス」と呼ばれる以下のメッセージを送信します。 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a (文字列表現: "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n") 理由 なぜこの文字列なのか一見して分かりづらいですが、理由としてはHTTP/2クライアントが間違えてHTTP/1.1サーバと接続しようとした際に素早く切断されるようにするためである。HTTP/1.1では改行文字(\r\n)を終端文字としているため、それを待ち続けてしまうサーバ実装があったとしてもこのメッセージを送信することで(

    HTTP/2 Connection Prefaceの理由と経緯 - ASnoKaze blog
    W53SA
    W53SA 2023/09/06
  • 逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog

    『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse

    逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
    W53SA
    W53SA 2023/07/18
  • 一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog

    ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 (あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。) サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)

    一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog
    W53SA
    W53SA 2022/07/04
  • 40年越しにTCPの仕様(RFC793)が改訂される RFC9293 - ASnoKaze blog

    2022/08/09 追記 「RFC 9293 Transmission Control Protocol (TCP)」として正式なRFCが出ました TCPのコア部分の仕様は1981年に発行された「RFC793 TRANSMISSION CONTROL PROTOCOL」で標準化されています。 この、RFC793の改訂版となる「Transmission Control Protocol (TCP) Specification」は、2013年からIETFのTCPM WGで議論されてきましたが、4月4日にIESGによって承認されました(参考URL)。現在はRFC出版の準備に入っています(新しいRFC番号はこの後正式に決まります) www.ietf.org 改めてTCPの仕様を読みたい場合はこのドキュメントを読むのが良さそう。 概要 この改訂版の仕様(通称 rfc793bis)は、RFC793が

    40年越しにTCPの仕様(RFC793)が改訂される RFC9293 - ASnoKaze blog
    W53SA
    W53SA 2022/04/13
  • 新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog

    新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等

    新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog
    W53SA
    W53SA 2022/03/24
  • 時間順にソート可能なUUIDv6, UUIDv7, UUIDv8の提案仕様 - ASnoKaze blog

    IETFに「New UUID Formats」という提案仕様が提出されています。 これは、時系列順にソート可能なUUID version 6, UUID version 7, UUID version 8を新しく定義するものです。 詳しい背景は提案仕様にゆずりますが、ULIDを始めとして、時系列順にソート可能な一意な識別子を利用したいというユースケースがあります。例えば、データベースのキーとして使えば、ソートせずとも順番に並びますし、書き込む際も順々に書き込めるのでデータアクセスが局所的になります。 今回は簡単に、それぞれのUUIDのフォーマットを眺めていきます。なお、フォーマットは異なりますが、バージョンを示す値は同じ位置にあります。 UUIDv6 UUIDv6は128bit長で、UUIDv1と似てるフォーマットを取ります。 1582年10月15日(グレゴリオ暦)からの100ナノ秒単位で

    時間順にソート可能なUUIDv6, UUIDv7, UUIDv8の提案仕様 - ASnoKaze blog
    W53SA
    W53SA 2021/04/28
  • HTTPコネクションでIPパケットをProxyさせる、新しいCONNECT-IPメソッドの仕様 (RFC 9484) - ASnoKaze blog

    2022年7月追記: この記事は古くなっています。現在の最新仕様では、拡張CONNECTメソッドを使うことになってます asnokaze.hatenablog.com 確立したHTTP/3コネクションをVPNのように使う、MASQUEという仕組みがIETFで議論されています。 以前書いた記事では、UDPパケットをProxyさせるCONNECT-UDPという提案仕様を紹介しました。 asnokaze.hatenablog.com その後、同様に確立されたHTTP/3コネクション上で、IPパケットをトンネリング可能にする「The CONNECT-IP HTTP Method」という仕様が提案されています。 CONNECT-UDPと同様に経路上の第三者にはただのHTTP/3通信を行っているようにしか見えないため、検閲やブロッキングに対して耐性があると思われます。 それでは簡単に見ていきましょう。

    HTTPコネクションでIPパケットをProxyさせる、新しいCONNECT-IPメソッドの仕様 (RFC 9484) - ASnoKaze blog
    W53SA
    W53SA 2021/04/26
  • ChromeのHTTP/2サーバプッシュサポート廃止検討と、103 Early Hintsについて - ASnoKaze blog

    ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様 背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。 たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。(クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます) そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中

    ChromeのHTTP/2サーバプッシュサポート廃止検討と、103 Early Hintsについて - ASnoKaze blog
    W53SA
    W53SA 2020/11/14
  • HTTP/3の解説を書いた (2020/06/01) - ASnoKaze blog

    @flano_yukiがHTTP/3について書きました。(無料です。 2020年6月時点の内容となっています。概ねQUICやHTTP/3の大枠は固まっており、2021年の内容と照らし合わせても、大きな変更はありません。PDFを下に貼ってあります。 , (宣伝) また、2021年6月にアップデートも含め、WEB+DB PRESS Vol.123に記事を書かせていただいております(有料) gihyo.jp http3-note https://github.com/flano-yuki/http3-notePDFを置きました 1. はじめに(HTTP/3と概要) 2. QUICについて 3. HTTP/3について 4. HTTP/3 拡張仕様と応用 5. (執筆予定) 実装、ツール紹介 公開形式は、そのうちなんとかするかも 内容 1. はじめに(HTTP/3と概要) 1.1 はじめのはじめ

    HTTP/3の解説を書いた (2020/06/01) - ASnoKaze blog
  • 1