プライム・ストラテジー「KUSANAGI」の開発チームの石川です。 「KUSANAGI」はWordPressをはじめとするCMSを高速に動作させる世界最速クラスの仮想マシンです。わたしたちは「KUSANAGI」を開発して皆様にご利用いただくほか、お客様のウェブサイトを「KUSANAGI」で運用しています。 この連載では、「KUSANAGI」の開発やお客様とのお話の中で感じた課題や実際の運用の中で得た知見などをお伝えしています。 今回は次世代のHTTPとも呼ばれる「HTTP/3」の裏側で使われている「QUIC(クイック)」についてお話ししたいと思います。 Googleが通信パフォーマンス改善について追求した「QUIC」 QUICはもともとGoogleによって設計されたトランスポート層の通信プロトコルです。 Googleがプロトコルを開発することを意外に思う人がいるかもしれませんが、Googl
HTTP/3 From A To Z: Core Concepts — Smashing Magazine
After almost five years in development, the new HTTP/3 protocol is nearing its final form. Earlier iterations were already available as an experimental feature, but you can expect the availability and use of HTTP/3 proper to ramp up over in 2021. So what exactly is HTTP/3? Why was it needed so soon after HTTP/2? How can or should you use it? And especially, how does it improve web performance? Let
本記事は、TechFeed Experts Night#13 〜 HTTP3/QUIC…Webプロトコル最前線のセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。 本セッションの登壇者 セッション動画 Fastlyの奥一穂と申します。今日はHTTP/3時代の優先度制御についてお話したいと思います。 仕事ではFastlyでTLSやQUICなどのHTTPのプロトコルスタックの開発に携わっています。その傍ら、本日お話するRFC 8297(103 Early Hints)やRFC 9218(Extensible Priorities)の著者を務めています。 HTTPの高速化の歴史とHTTP/3 最初にHTTPの高速化の歴史について振り返ってみましょう。 HTTP/1.1(1997) … 複数の
Web における Beacon の変遷 (sendBeacon(), fetch() keepalive, fetchLater()) | blog.jxck.io
Intro ページを閉じる際に何かしらの情報をサーバで収集したいケースがある。 これを Beacon の送信(Beaconing)と呼び、ブラウザではページ表示中に収集したパフォーマンス統計の収集や、広告タグによるトラッキングなどに用いられる。 しかし、「ページが閉じる直前に、サーバにリクエストを送信する」を確実に実行するのは実は難しく、これを標準技術で実現する過程で、複数の API が生まれるに至った。 各 API の策定経緯と、挙動の違いについて解説していく。 <img> での送信 最もプリミティブな Beacon の送信は、<img> を用いたものだった。 window.addEventListener("unload", () => { const beaconImage = new Image(1, 1); beaconImage.src = "https://telemetry
今回はRustを使って、簡単なHTTPサーバを実装してみましょう。HTTPは単純ですが生活インフラとしても必須となっているWebの根幹となる技術です。Rustに対する理解を深めると同時にWebの根幹となるHTTPについても学びましょう。 RustでHTTPを実装してみよう HTTPプロトコルとは？ 「HTTP(Hypertext Transfer Protocol)」とは、WebサーバーとWebブラウザの間でデータをやりとりするための通信規則（プロトコル）です。 1990年末にイギリスの物理学者ティム・バーナーズ＝リー氏と、ロバート・カイリュー氏によって設計されました。 HTTPプロトコルは、RFCとして公に発表されています。RFCとは、IETFが発行しているインターネットに関連する技術仕様などを共有するために公開される文書であり誰でも読むことができます。1996年にHTTP/1.0に関す
gRPCとは？gRPCベースのシステムの脆弱性診断とツール（前編） | セキュリティブログ | 脆弱性診断（セキュリティ診断）のGMOサイバーセキュリティ byイエラエ
札幌オフィス在籍の岸谷です。近年gRPCの利用がだいぶ普及してきましたね。今回はgRPCを利用するシステムの脆弱性診断と、そのためのツールについて書きたいと思います。 gRPCって何？ 本稿はgRPC自体の解説を目的としたものではありませんが、本題に進む前に簡単に概要に触れます。gRPCはGoogleで開発され、その後オープンソース化されたフレームワークです。grpc.ioには下記のようにあります。 gRPC is a modern open source high performance RPC framework that can run in any environment. 「環境を問わずハイパフォーマンスなRPC開発フレームワーク」ということで、XML-RPCやJSON-RPC、REST API開発用のフレームワークなどのように、他コンピュータ上のコードの呼び出しなどシステム間通
Go Conferenceは半年に1回行われるプログラミング言語Goに関するカンファレンスです。 石澤氏は、Goを使ったインターネットプロトコルのテストツール「protospec」の作成について発表しました。全2回。前半は、テストツール「protospec」の仕組みについて。 HTTP/2のサーバーをゼロから実装した時に感じたこと 石澤基氏：今日は、GoとOCI Artifactsを使ってインターネットプロトコルのテストケースを共有可能にするという話をしていきたいと思います。 私はカンムという会社でソフトウェアエンジニアをしています、石澤基と申します。カンムでは主にサービスのバックエンドやインフラ領域を担当していて、Goは個人的に書いているのも含めて、5年ぐらい前から書いたり読んだりしています。 私が所属するカンムでは、VISAのプリペイドカードをアプリですぐに発行して使える、「バンドルカ
[アップデート] ALB および CLB に HTTP Desync 緩和モードが機能追加されました | DevelopersIO
私の力不足により実機検証の内容はありません。アップデート内容およびその背景について触り程度にまとめました。 本日のアップデートで ALB および CLB が HTTP Desync 緩和モードをサポートするようになりました。 Application and Classic Load Balancers are adding defense in depth with the introduction of Desync Mitigation Mode 何がうれしいのか HTTP Desync 攻撃とは このアップデートの何が嬉しいのかを理解するには、まず HTTP Desync 攻撃 について知る必要があります。 近年では Web アプリケーションでは CDN やプロキシをフロントエンドに配置し、バックエンドのサーバーにリクエストを転送するような構成を一般的にとられているかと思います。まず
![[アップデート] ALB および CLB に HTTP Desync 緩和モードが機能追加されました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/876809e40a16193d45c580a01a3f67fc9a50a044/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Felastic-load-balancing.png)
https://www.oreilly.co.jp/books/9784814400669/ ひとえに読者の皆さんが買ってくれたおかげで、Real World HTTPを改訂し、このたび3版を上梓しました。ありがとうございます。2016年ごろから書き始めて、2017年に初版を出版したので、執筆段階からすると8年ほど経過しているのですが、これだけ長くこの本に関わり続けられるというのは、本書を買ってくださるみなさまのおかげです。 今回は、ひさびさに無料のミニ版も更新しました。本日、このブログと同時にリリースしました。よりミニ版が学習コンテンツとして使いやすくなるように、そもそもブラウザってどんな動きをするの？ というイントロの章をミニ版とオリジナル版に追加しました。 また、オリジナル版だけになりますが、HTTPが単なるブラウザとの通信を超えてプラットフォーム API化していっている流れに合わせ
あけおめ☆ 年末年始を長期休暇にしたせいで、起ち上がりが悪い。エンジニアたるもの、そんな時はコーディングだ。Pythonでモチベーションを取り戻すんだ！ その気持ちだけでクールなシステムを考案・構築してしまったので、書いていきたいんだけど、物事には順序がある。まずは HTTP API Gateway に認証をつけるとこから、ブログの暖機運転なのだ。 おさらいと公式 前に、API Gateway の基本的な部分は↓↓に書きました。 AWS API Gateway v2 の Terraform構成 | 外道父の匠 AWS API Gateway v2 HTTPの基礎練習 | 外道父の匠 認証の仕組みがなかったので、まぁこんなこともできるよねって意味で、オレオレ認証も書いたんだけど、その後すぐに公式で対応されたわけです。 API Gateway HTTP API が Lambda および IAM
RFC 9114: HTTP/3
Stream: Internet Engineering Task Force (IETF) RFC: 9114 Category: Standards Track Published: June 2022 ISSN: 2070-1721 Author: RFC 9114 HTTP/3 Abstract The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over Q
RubyKaigi 2023でのセキュアなDNSリゾルバの運用 ― DNS-over-HTTPSとDDR - KMC活動ブログ
こんにちは，id:hanazukiです．いよいよ明日からRubyKaigi 2023が始まりますね．私は昨日から松本入りして，今日は会場の設営をやっていて，ちょうどいま(17:00)，お昼休憩をとっています……．会期が終わったあとにまとめを書こう〜なんて思っているとたいていそのまま忘れてしまうので，今年は準備と並行して記事をしたためている次第です． 私は，RubyKaigiで来場者向けに提供しているWi-Fiの構築・運用を2017年から手伝っています．毎年おなじことをやっていてもおもしろくないというか，だんだんとやることが目減りしてしまいますよね．今年は何か新しいことをできないかと考えて，RubyKaigi会場ネットワークのDNSリゾルバをDNS-over-HTTPSに対応させることにしました． この記事では， DNS-over-HTTPSが普通のDNSとはどう違うのかを見てから， Rub
Intro IETF が策定する HTTP の仕様が更新されようとしている。 ここには、Cache の仕様も含まれており、そのなかで must-understand という Cache-Control のディレクティブが追加されている。 このディレクティブが追加された経緯と仕様について解説する。 Cache と Status Code RFC 7234 では、新しいステータスコードを策定する際に、キャッシュに関して以下のように書かれている。 The definition of a new status code ought to specify whether or not it is cacheable. Note that all status codes can be cached if the response they occur in has explicit freshnes
GitHub - pgrok/pgrok: Poor man's ngrok - a multi-tenant HTTP/TCP reverse tunnel solution through SSH remote port forwarding
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
mime-typeに関する「データベース」であるfreedesktop.org.xmlに著作物性があるかどうか、という話。 例えばそのデータベースが下記のようなものだったら、これは単なる網羅的な事実の列挙であって、体型的な構成に創作性がないので「データベースの著作物」としての保護の対象にはならない。
max-age=0って何のメリットがあるの？
こんにちは。株式会社プラハCEOの松原です。 先日プラハチャレンジの参加者に「Cache-Control: max-age=0って何の意味があるの？毎回サーバーに問い合わせてたらキャッシュのメリットがないのでは？」と聞かれたので、それについて思ったことをまとめてみます TL:DR; どでかいレスポンスを毎回取得しなくて済む 内容が更新されたらすぐ知りたいけどめっちゃ重いから毎回受け取りたくないリソースに向いてる 説明 例えば、内容が変わったらすぐに反映させたいどでかい画像を返してくるサーバーに複数回アクセスするケースを考えてみます レスポンスにmax-age=0が指定されている場合、2回目以降も毎回サーバーまでは問い合わせるけど変更がなければレスポンスのボディにはどでかい画像は含まれていない状態で返ってきます。空っぽです。1回目のレスポンス（どでかい画像）をクライアントがキャッシュしている
副作用（メール送信、データの更新、削除など）のある処理を、HTTP GETで起動できるように設計してはいけないっていう例じゃねーかなこれも 管理者用初期化URLを踏んでWebサービスのデータをふっとばした話 - Qiita
こんにちは、去年の8月に入社しましたMSP事業部エンジニアリンググループの鈴木です。 本記事は、Apache HTTP Server（以降「Apache」と略す）のgraceful stop/restart（以降、2つを指す場合「graceful」と略す）について調査・理解したことをまとめたものになります。具体的には以下について調査しました[※1]。 gracefulの概要、通常のstop/restartとの違いおよびユースケース systemd（systemctl）でgracefulを実行する方法 gracefulを実行する3つのコマンドの動作や関係性 gracefulを実行するコマンドの動作確認（ドキュメントの裏取り） 付録：graceful関連のソースコード解析（理解できている範囲のみ） なお、今回は私個人の学びの一環としてgracefulの基本的なことから調査しましたので、内容とし
Firefox 87 trims HTTP Referrers by default to protect user privacy – Mozilla Security Blog
Firefox 87 trims HTTP Referrers by default to protect user privacy We are pleased to announce that Firefox 87 will introduce a stricter, more privacy-preserving default Referrer Policy. From now on, by default, Firefox will trim path and query string information from referrer headers to prevent sites from accidentally leaking sensitive user data. Referrer headers and Referrer Policy Browsers send
HTTP上でL2VPNを実現する Proxying Ethernet in HTTP について - ASnoKaze blog
『Proxying Ethernet in HTTP』という仕様がGoogleのAlejandro R Sedeño氏から提出されています。これは、HTTP上でイーサネットフレームを送受信させるための仕様です。 背景として、IETFでは、Masque WGにおいてHTTPコネクション上で通信をトンネリングする仕組みの標準化を行っています。 RFC 9298 Proxying UDP in HTTP Proxying IP in HTTP すでに標準化が進められている、上記の仕様に続きイーサネットフレームを取り扱えるようにするというのが今回の提案です。ユースケースについては、L2VPNを実現するのに利用する例が挙げられています。 Proxying Ethernet in HTTPの概要 『Proxying Ethernet in HTTP』では、"RFC 9297 HTTP Datagram
著者が実装したQUICプロトコルサーバー・クライアントの解説になります。 今回はInitialPacketを解析してClietnHelloを受け取り解析するところまでになります。（ServerHello返すところまで実装してますが、解説は残念ながら間に合いませんでした……！すみません！）
某のフィッシングキットから見る、調査のときに留意したいクローキングのこと - 切られたしっぽ
はじめに フィッシング詐欺は企業にも個人にも迫る身近なサイバー脅威の1つであり、それが占める被害件数の割合はサイバー攻撃全体で見てもおそらく最大クラスです。 大規模な SOC や CSIRT に所属している方にとっては、対応することが多いアラート・インシデントの一つになっているのではないかと思います。 もちろんアラート・インシデントがあれば対応者がフィッシングサイトの調査をする必要が出てきますが、ここで一つ課題になるのは クローキング の存在です。 クローキングは一般的なIT用語なのですでに知っている方も多いと思いますが、いわゆるアクセス元の情報を頼りに表示するコンテンツを変える技術のことですね。 wacul-ai.com フィッシングサイトもクローキングによってフィッシング用コンテンツと良性コンテンツの表示を切り替えているのですが、問題はこのクローキング技術は対応者・リサーチャー側からは
Hi, I’m Mark Nottingham. I usually write here about the Web, protocol design, HTTP, and Internet governance. Find out more. Comments? Let's talk on Mastodon. @mnot@techpolicy.social other HTTP posts Yet More New HTTP Specs Wednesday, 8 June 2022 A New Definition of HTTP Monday, 6 June 2022 How Multiplexing Changes Your HTTP APIs Sunday, 13 October 2019 Designing Headers for HTTP Compression Tuesda
HTTP/3とは何か？−UDPベースの高速新プロトコルの概要
HTTP/3とは何か？−UDPベースの高速新プロトコルの概要 TL;DR 2018年11月、バンコクでIETF（Internet Engineering Task Force）が開催され、新しいインターネットドラフトが採択されました。また、HTTP/2の後継プロトコル、QUICトランスポートプロトコルは「HTTP/3」に名称変更されました。 HTTP/3はUDP（User Datagram Protocol）を使用する通信方式で、GoogleやFacebookなどの有名インターネット企業ですでに採用されています。Chromeを使ってGoogleのサービスに接続しているユーザーは、恐らく知らないうちにQUICを使用しているはずです。 新バージョンのHTTPプロトコルは、ベアメタルで低レベルのUDPプロトコルの恩恵を受けつつ、旧バージョンのTCP層にあった多くの新機能を定義します。つまり、既存
[アップデート] ALBでエンドツーエンドのHTTP/2サポートによりgRPCワークロードが可能になりました | DevelopersIO
本日のアップデートにより Application Load Balancer（以下、ALB）でエンドツーエンドのHTTP/2がサポートされ、加えて gRPC プロトコルが利用可能になりました。 Application Load Balancers enables gRPC workloads with end to end HTTP/2 support ALB でエンドツーエンドの HTTP/2 通信が可能に 以前より ALB は HTTP/2 に対応していましたが、ALB - ターゲット間の通信は HTTP/1.1 に変換されていました。そのため、エンドツーエンドでの HTTP/2 利用できませんでした。この仕様により、HTTP/2 をトランスポートに利用する gRPC を ALB で利用することは出来ないため、NLB または CLB を利用されていたかと思います。 今回のアップデートで
インターネットの標準として使われてきたプロトコルが置き換わるかもしれない。インターネットの通信プロトコルなどの標準化を手掛けるIETF（Internet Engineering Task Force）は2021年5月27日（米国時間）、通信プロトコル「QUIC（Quick UDP Internet Connections）」をRFC 9000として勧告した。これが長らく使われてきたTCP（Transmission Control Protocol）に取って代わる可能性があるとして関心を集めている。 IETFが標準化したQUICは、2013年に米Google（グーグル）が発表した、大量のアクセスを高速に処理するためのプロトコル「QUIC」を発展させたものだ。グーグルのQUICはWeb専用で、UDP（User Datagram Protocol）を利用する通信プロトコルであり、独自の暗号化手法
この記事は GraphQL Advent Calendar 2020 14 日目の記事です。 前回の記事は @joe-re さんの 「ライブラリの実装からCursor-based paginationにおけるcursorのフォーマットのベストプラクティスを探る」 でした。 前置き GraphQLは2010年代後半に出てきた技術の中でも個人的に特に強力なアプリケーション実装パターンの一つだと思っているのですが、シンプルな実装なのに利用用途が豊富にあることと利用する立場が違うと全く印象を抱く事から全体像を掴みづらく、本来持つべきポテンシャルに対してまだ認知が広がっておらず利用されていないように感じます。 今回はサーバーサイドからの視点を中心にGraphQLを構築する要素を分解して解説するのとともに、それを利用した際にWebアプリケーション開発やそれに関わるエンジニアに起きうる変化について書いて
👋 This page was last updated ~2 years ago. Just so you know. Thanks to my sponsors: L0r3m1p5um, James Rhodes, (18D)eezNuts, Dylan Anthony, Guilherme Neubaner, Aiden Scandella, Berkus Decker, Matt Campbell, Mike English, Samit Basu, Christoph Grabo, John Horowitz, Joseph Montanaro, Alan O'Donnell, Mark Tomlin, Wyatt Herkamp, Michal Hošna, Sindre Johansen, Colin VanDervoort, Stephan Buys and 264 mo
Google ChromeやEdge、FirefoxなどのWebブラウザーを利用してWebサイトを閲覧したり、メールの送信先をアドレスで指定したりするときに欠かせないのがDNS（Domain Name System）だ。URLやメールアドレスに含まれるドメインからサーバーのIPアドレスを調べる「名前解決」に使う。 DNSサーバーには、名前解決に使うアドレスを示すレコード（AやAAAA）やメールサーバーのホストを示すレコード（MX）のほかに、メールのセキュリティー機能などに使うテキスト情報のレコード（TXT）、特定の用途（プロトコル）に使うホスト名やポート番号などを示すレコード（SRV）などが登録されている。このDNSに新しいレコード「HTTPSリソースレコード」が追加され、利用される機会が増えている。 インターネットイニシアティブ（IIJ）が調査した結果によると、同社のDNSサーバーへの問
CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack | Google Cloud Blog
Hear monthly from our Cloud CISO in your inboxGet the latest on security from Cloud CISO Phil Venables. Subscribe A number of Google services and Cloud customers have been targeted with a novel HTTP/2-based DDoS attack which peaked in August. These attacks were significantly larger than any previously-reported Layer 7 attacks, with the largest attack surpassing 398 million requests per second. The
The latest news and insights from Google on security and safety on the Internet
デフォルトでCookieをオリジンに紐づける、ChromeのOrigin-Bound Cookies - ASnoKaze blog
Blinkの開発者メーリングリストで「Intent to Prototype: Origin-Bound Cookies」という議論が行われています。 Cookieをより安全にするために、デフォルトでCookieをオリジンに紐づけるようにする提案です。Cookieをset-cookieしたオリジン以外からは、そのCookieにアクセスできないようになります。 詳しい背景や仕組みについては次のページから確認できます。 github.com かんたんに、Origin-Bound Cookiesの動作をみていきましょう。 例 オリジンは、スキーム、ホスト名、ポートの組です。それらのうち一つでも異なれば、オリジンが異なることになります。 例えば、次のようになります。 http://example.comによってセットされたcookieは、http://example.comにのみ送信されます。ht
普段Go書いているときにそこまで気にしてなかったが、ふと気になったので色々パターンを挙げてみる。なおこの記事には「答え」が書かれてないので、みなさんの意見を聞かせてください。 複数の引数を取るパターン一覧 そのまま引数を羅列する 複数の引数をまとめたstructを取る Functional Options Pattern そのまま引数を羅列する 例えばHTTPリクエストを行うような関数があったとして、 func Request(ctx context.Context, method http.Method, _url string, query url.Values, formValues url.Values) error { // do something } というシグネチャが考えられる。 実際にnet/http.NewRequsetWithContext は func NewReq
AWS Lambdaで突如としてHTTPヘッダが消失し、それにより悩まされることとなった日の経験を共有します。この問題がどのように生じ解決に至ったのか、また、私たちが学んだ教訓について述べていきます。 対象のLambda関数 今回問題が起きたLambda関数では、ランタイムにNode.jsを利用していました。Lambda関数の中には、外部のAPIサーバに対するリクエスト処理が含まれます。 環境情報は以下の通りです。 ランタイム: Node.js 18 (18.18.2) リクエストライブラリ: ky v1.0.1 エラーの発生 ある時、APIサーバからのレスポンスが"415 Unsupported Media Type"というエラーで返ってくるようになりました。エラーメッセージは以下のようなものです。 問題が起きる前は一度も発生していないエラーでしたが、一度発生した後は、全てのリクエストが
HTTPでファイルをアップロードする時、ネットワークの寸断などによりアップロードが中途半端に終わってしまうことがあります。アップロードが途中まで成功したとしても、一度切断するとそこから再開する方法は標準化されていません。 (PUTリクエスト + Rangeヘッダによる再開をサポートしているシステムもありますが標準化されてはいません。 参考URL) そこで、再開可能なアップロードの仕組みを定義した「Resumable Uploads Protocol」という仕様がIETFに提出されています。この仕様は、Transloadit Ltd, Apple Inc, Cloudflare などの方々の共著になっています。 Resumable Uploads Protocol の概要 「Resumable Uploads Protocol」は、一度中断しても再開可能なアップロード方式を定義しています。
103 Early Hints とは何か？ ～マイナーだけど革新的なHTTPステータスの世界～ - Repro Tech Blog
はじめに みなさまこんには。日々 Booster で楽しくコードを書いている杉浦(sugi) です。 Booster プロジェクトではタグを入れるだけでサイトを高速化できる「Repro Booster」という製品を作っていますが、そのためにも日々さまざまな最適化手法を調査・模索しています。 その中で個人的に期待しているのが、 103 Early Hints というHTTPステータスコードです。 この記事では Repro Tech Meetup #9 で行った発表(資料)を元に、103 Early Hintsはどのような仕組みなのか、なぜ高速化につながるのか、さらに現状の実装に関して解説します。 ちょっとマイナーな内容ですが、知っておくとウェブパフォーマンス最適化の大きな武器になるかもしれません。 103 Early Hintsの背景 従来のHTTP通信の課題 通常のHTTP通信においては、
シングルバイナリにこだわる - AWS Lambda編 / Nature Bath vol.6
Nature Bath vol.6【勉強会】みんなのGo言語 執筆陣による「Go開発・運用の現場」の発表資料です https://nature.connpass.com/event/194611/
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Googleが設計した次世代通信プロトコル「QUIC」とは？
HTTP/3時代の優先度制御 - Web配信の高速技術 @kazuho
Rustで有名アルゴリズムに挑戦(17) RustでHTTPサーバを実装してみよう
HTTP/2をゼロからの実装したときに感じた“難しさ” 僕がGoで仕様準拠テストツール「protospec」を開発した理由
Real World HTTPの第3版ができあがりました | フューチャー技術ブログ
AWS API Gateway HTTPのAuthorizer設定 | 外道父の匠
「nginx」がHTTPステータスコード『103 Early Hints』に対応 ～Webの高速化に期待／「nginx-1.29.0」Mainlineでサポート開始
Cache-Control: must-understand ディレクティブとは何か | blog.jxck.io
freedesktop.org.xmlの著作物性 - 西尾泰和のScrapbox
副作用（メール送信、データの更新、削除など）のある処理を、HTTP GETで起動..
Apache HTTP Serverのgraceful stop/restartを理解する
QUICの参考書―ゼロから作るRust言語による実装解説―Initial Packet編：MishProto
Server-Sent Events, WebSockets, and HTTP
TCPに取って代わるか？グーグル発の新標準プロトコル「QUIC」とは
GraphQLはサーバーサイド実装のベストプラクティスとなるか - Qiita
The HTTP crash course nobody asked for
「HTTPSレコード」が技術標準のRFCに、高速通信を普及させる起爆剤となるか
PythonのWebフレームワーク「Django」のHttpRequestオブジェクトを徹底解説
DNS-over-HTTP/3 in Android
Goで複数の引数を取る関数やメソッドをどう書くのがいいのか - ぱいぱいにっき
ポストモーテム: AWS Lambda内のリクエストからHTTPヘッダが消えた日
すべての「Chrome」をHTTPSファーストに、Googleが本腰を入れる／自動HTTPSアップグレード、HTTPダウンロードの警告、HTTPSファーストモードの拡大を実施
HTTPで再開可能なアップロードを可能にする提案仕様 - ASnoKaze blog
yasu-investment.hatenablog.com
ameblo.jp/high-hopes
anond.hatelabo.jp
news.yahoo.co.jp
wp.techfactory.itmedia.co.jp
ameblo.jp/ohohohoho12345