Reverse HTTP Transport が描く新しい Web サービスデプロイ構成 | blog.jxck.io
Intro IETF の httpbis で、 Reverse HTTP Transport という仕様が提案されている。 Reverse HTTP Transport https://www.ietf.org/archive/id/draft-bt-httpbis-reverse-http-01.html この仕様は、 Origin サーバの前に何かしら Intermediaries (Loadbalancer, Reverse Proxy, CDN etc)があるのが一般的な現代の Web サービス構成において、非常に革新的なアイデアを取り入れたプロトコルと言える。 まだ v01 という初期段階ではあるが、発想が非常に面白かったので、読書メモを残す。 登場人物 ベースとして HTTP の話にはなるが、登場人物が多いため Client/Server という「相対的な役割」で話をすると、紛
HTTP/2 と gRPC に対するよくある誤解。 - ねののお庭。
以前 .NET ラボで 「C# と HTTP/2 と gRPC」というタイトルで登壇しました。その時のスライドがこちらなのですが、ちらほら反応を頂きました。その結果、HTTP/2 や gRPC について勘違いしている人がちょこちょこいる事が分かったので、少し補足を書こうと思います。 blog.neno.dev 1. HTTP/2 で向上するのはスループットであって、1リクエストあたりの応答時間ではないよ。 HTTP/2 を使うからといって、1 リクエストあたりの応答時間が短くなるわけではないのです。 まず、1 HTTP リクエストあたりにかかる時間を、RTT とかいったりします。 1 RTT の内訳はだいたいこんな感じになります。 1 RTT = ネットワーク上で往路にかかる時間 + サーバの処理時間 + ネットワーク上で復路にかかる時間 HTTP/2 になったからといって、ネットワークを
DNS over HTTPS（DoH）の気になる Web Browser 実装を確認
Firefox の通信キャプチャ シナリオ 1-1 の通信を確認します。 まずは最初の Web Browser → DoH リクエストです。 Host: TEST_SERVER Accept: application/dns-message Accept-Encoding: Content-Type: application/dns-message Content-Length: 128 Cache-Control: no-store, no-cache Connection: keep-alive Pragma: no-cache 0x00 0x00 0x01 0x00 0x00 0x01 0x00 0x00 | ....... 0x00 0x00 0x00 0x01 0x03 0x77 0x77 0x77 | ......ww 0x06 0x67 0x6f 0x6f 0x67 0x6c
Google AppScriptでHTTP POST(doPost)を受け付ける最小コード (2022年夏) - Qiita
Google AppScriptでHTTP POSTを受け付ける方法は、ググればかなり出てきます。 2021年頃の仕様変更(参考URL1 2)によって console.log や Logger.log の出力はGoogle Cloudに紐づける必要があり、ちょっとした開発は面倒です。 ここでは、ともかくHTTP POSTのBodyをSpreadsheetに出力するだけの最小コードを用意しました。これにより e の出力をとりあえず確認できるようになります。 function doPost(e) { const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheets()[0]; sheet.getRange("1:1").insertCells(SpreadsheetApp.Dimension.ROWS); sheet.getRange(
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-note にPDFを置きました 1. はじめに(HTTP/3と概要) 2. QUICについて 3. HTTP/3について 4. HTTP/3 拡張仕様と応用 5. (執筆予定) 実装、ツール紹介 公開形式は、そのうちなんとかするかも 内容 1. はじめに(HTTP/3と概要) 1.1 はじめのはじめ
Cloudflare の HTTP リクエストログを Amazon S3 に出力して Amazon Athena で分析してみた | DevelopersIO
Cloudflare の HTTP リクエストログを Amazon S3 に出力して Amazon Athena で分析してみた ウィスキー、シガー、パイプをこよなく愛する大栗です。 最近 Cloudflare を触っています。運用を考えるとアクセス状況の把握が必要になります。標準で分析ダッシュボードも有るのですが、詳細ログを分析したくなることがあります。今回は HTTP リクエストのログを S3 へ出力して Amazon Athena で分析してみます。 Cloudflare Logpush Cloudflare はログを確認するための手段を複数用意しています。今回はこの中の Logpush に焦点を当てます。なお Logpush は Enterprise Plan での提供となっています。 Logpush: 外部のストレージサービスへバッチでログをプッシュします Logpull: RE
HTTP Toolkit
HTTP Toolkit is a beautiful & open-source tool for debugging, testing and building with HTTP(S) on Windows, Linux & Mac.Join 506,000 happy developers: Today I discovered this amazing open source tool call HTTP Toolkit that you can use to intercept HTTP and HTTPS traffic for analysing and debugging. In case you want to look at header and body of your HTTP messages then this tool is really amazing.
QUICをゆっくり解説(1)：QUICが標準化されました | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 不定期連載を始めます IIJ-II 技術研究所 技術開発室の山本です。私はプログラミング言語HaskellでHTTP/2とTLS 1.3を実装した後、もっぱらQUICを実装することに時間を費やしてきました。 ご存知の方もいらっしゃると思いますが、今年の5月にQUICの仕様がRFC9000として公開されました。このRFCは実によく書かれているので、読みこなせばQUICの全容が掴めるでしょう。 しかし仕様は膨大ですし、実際に実装してみて初めて腑に落ちることもあります。そこでこの機会に、実際にQUICを実装した経験者目線で、QUICの解説をしていきたいと思います。なんとなくTCP/IPを分かっている方が、ある程度QUICの理解ができることを
API Meetup Online #3で限定公開URL（Capability URLs）について話をしてきました。 | フューチャー技術ブログ
API Meetup Online #3で限定公開URL（Capability URLs）について話をしてきました。 API Meetup Online #3での登壇をお誘いをいただいたので、以前から調査していたものの、発表の機会のなかった限定公開URLについて調べていた内容を発表しました。 Real World HTTPの第3版が出るとしたら（具体的な計画とかはないですが）入れるかも、なネタでした。どちらかというとコンシューマー向けな機能な気がしますが、hipchatは以前、共有したファイルがこのCapability URLsだったという噂も聞きますし、サービスによってはエンプラでも使っているものもあるかもしれません。自分で実装するにしても、利用する側だったりといろんな立場でこの機能に関わる場合に、その安全性を評価する物差しは持っておきたいな、ということで調べました。 セキュリティ的には
Real World HTTP 第2版はなぜ1.5倍になったのか | フューチャー技術ブログ
Real World HTTP 第2版が2020/04/20出版されました。第2版が出版されるというのは、初版をみなさまが買ってくださったおかげです。どうもありがとうございます。紙媒体は先行入荷する書店さんではすでに入っているようです。オライリーのウェブサイトから電子版を購入することもできます。 4/17新刊『Real World HTTP 第2版 歴史とコードに学ぶインターネットとウェブ技術』オライリー（978-4-87311-903-8）渋川よしき 著◆「オライリー」棚にて展開中！Webテクノロジーの基礎となるHTTPの仕様を網羅的に学べる学習書が内容を充実させて改訂！ pic.twitter.com/k86zXGaHe9 — 書泉ブックタワーコンピュータ書 (@shosen_bt_pc) April 17, 2020 Real World HTTPの初版の執筆時にも、ネットで見かける
Let's Encryptを使用しているウェブページをブロックするプロキシサーバー - Qiita
Let's Encryptはドメイン認証証明書を無料で発行してくれるたいへん素晴らしいサービスです。ウェブサイトをHTTPSで提供するためには証明書が必要ですが、Let's Encryptの登場以前は認証局から有料で証明書を発行してもらうのが主流でした。それを無料で発行してもらえるのは大変ありがたいことです。また、発行プロセスは自動化されておりとても簡単です。筆者も個人のウェブサイトは全てLet's Encryptで証明書を取得しています。 ところが、Let's Encryptが発行する無料の証明書なんて信頼できないという教義を信奉するタイプの人々も存在するようです。筆者は最近Twitterで見かけました。ということで、そのような思想を持つ方も安心してインターネットを利用できるように、Let's Encryptによって発行された証明書を使用しているウェブサイトのみブロックするプロキシサーバ
HTTP のプライオリティが大きく変わろうとしている話（その他 IETF 105 雑感）
先週、モントリオールで開催された IETF 105 に参加してきました。 いろんなことがあったのですが、個人的に一番大きかったのは、HTTP/3 からプライオリティ（優先度制御）まわりの仕様を落とすことが決定したこと。 HTTP/3 は、トランスポートプロトコルである QUIC の上で動作する、次世代の HTTP プロトコルです。その設計は、QUIC ワーキングググループが、HTTP ワーキンググループから委託され、HTTP/2 の機能を移植する、という形式を取っています。 ところが、５月にロンドンで開催された QUIC ワーキンググループの中間会議で、一部参加者から HTTP/3 の優先度制御に対する不満が表明されたのです注1。それを受けて、QUIC ワーキンググループでは、HTTP/3 の優先度制御にあった HTTP/2 のそれとの差異を少なくする作業を進める一方、HTTP ワーキング
ライブ動画配信プロトコル（HTTP Live Streaming, HLS）の概要図解メモ（AbemaTV／FRESH!）
FRESH!で再生が止まってしまったときに、Chrome DevToolsのNetworkタブを見ていたところ、.m3u8というファイルの取得に失敗していることが分かりました。そこから、.m3u8ファイルと.tsファイルを用いて実現されるライブ動画配信の仕組みHTTP Live Streaming (HLS)の挙動について調べ、実際の通信内容と比較して、クライアント側の動作や、ファイルの内容などの仕組みが見えてきました。 その基本的なところについての理解を図解してみたので、ここにメモ＆紹介しておきます。 実際の挙動については、サイバーエージェントの動画配信サービス「FRESH!」および、「AbemaTV」の挙動を参考にしました。 目次 1. HTTP Live Streaming (HLS)2. ２種類のファイルを用意して動画配信する2.1. .tsファイル（動画）2.2. .m3u8（プ
Big Sky :: golang のミドルウェアとして組み込むだけでパフォーマンス改善が見込める「HTTP Coala」
ミドルウェアとして Use するだけでパフォーマンスが向上するなんて夢の様な話はないと思っていたけど、HTTP Coala はそれをやってのけている様です。 goware/httpcoala · GitHub Go http middleware handler for request coalescing https://github.com/goware/httpcoala ちょっと信じがたかったので、まずはベンチマークを取ってみた。 Coala 未使用 package main import ( "net/http" "github.com/zenazn/goji" "github.com/zenazn/goji/web" ) func main() { goji.Get("/", func(c web.C, w http.ResponseWriter, r *http.Reques
作って学ぶ 「Https Man in The Middle Proxy」 in Go - ( ꒪⌓꒪) ゆるよろ日記
ᕕ( ᐛ )ᕗ こんにちわ、しいたけです。 webのhttps化が推進される昨今ですね? https通信は経路上での通信内容が盗聴・改竄されるのを防ぐことができますが、開発用途でhttps通信の内容を確認したい場合が稀にあります。 そのような場合は mitmproxy などを導入すればよいのですが、せっかくなので実際にこのようなProxyをGoで実装してみて、 中間者攻撃(Man-in-The-Middle Attack)がどのような手法でhttps通信を盗聴・改竄するのか確かめてみました。 実際に書いたProxyのコードはこちらです yuroyoro/mitm_proxy_sample https proxy と HTTP CONNECT tunneling まず、通常のhttps Proxyの動作を確認してみましょう。 httpsでは、ProxyはクライアントからのCONNECTメソッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP/3 Deep Dive | HTTP/3's value, features, and use cases
Python script to detect if an HTTP server is potentially vulnerable to the log4j 0day RCE (https://www.lunasec.io/docs/blog/log4j-zero-day/)
日本語 | HTTP/3 explained
What Is DNS-Over-HTTPS and How Does It Work?
Analyse your HTTP response headers
