「HTTP/3」がHTTP-over-QUICの新名称に。IETFのQUICワーキンググループとHTTPワーキンググループで合意 － Publickey
現在IETFで仕様策定が進められている、UDPをベースに効率的で高速な通信を実現するためのプロトコル「QUIC」をトラスポート層に用いる新しいHTTPの名称が「HTTP/3」になることが決まりました。 HTTP/3のベースはGoogleが開発したQUIC。IETFで標準化へ もともとQUICは、Googleが高速なHTTPの通信を実現するためのプロトコルとして2013年に発表し、同社のChromeブラウザやクラウドサービスなどに実装してきました。 QUICは、従来のHTTPでトランスポート層に用いられているTCPの代わりに、UDPを用いています。 TCPはエラー訂正機能などを備え信頼性の高い通信が可能な一方、比較的オーバーヘッドの大きなプロトコルです。そこでTCPの代わりに通信の信頼性は保証されないもののオーバーヘッドの小さいUDPを用い、独自に一定の信頼性を保つ実装を組み込みつつHTTP
HTTP/3
The protocol that’s been called HTTP-over-QUIC for quite some time has now changed name and will officially become HTTP/3. This was triggered by this original suggestion by Mark Nottingham. The QUIC Working Group in the IETF works on creating the QUIC transport protocol. QUIC is a TCP replacement done over UDP. Originally, QUIC was started as an effort by Google and then more of a “HTTP/2-encrypte
ソースに一行追加するだけですべての HTTP 通信をロギングするモジュールを書いた #golang - 詩と創作・思索のひろば
こちらです。Perl でいうと Devel::KYTProf に性質がちかい。 motemen/go-loghttp · GitHub (GoDoc) 使用例 たとえばこういうコードに… package main import ( "io" "log" "net/http" "os" ) func main() { resp, err := http.Get(os.Args[1]) if err != nil { log.Fatal(err) } io.Copy(os.Stdout, resp.Body) } % go run main.go http://example.com/ <!doctype html> ... 一行追加すると: package main import ( "io" "log" "net/http" "os" _ "github.com/motemen/go-lo
オブジェクト指向とはまったく違うClojureの世界と実際のWeb開発 - 紙箱
今回は、記事ではなく、【京都】LINE Developer Meetup #38で、ClojureとWeb開発について話したので、その時のスライドを紹介します。 こちらからご覧ください。（注：Slideshareの仕様なのか、元のスライドでは改行位置など揃っていたのが崩れてしまっています） Clojureの世界と実際のWeb開発 from Tsutomu Yano
How HTTPS Works
How HTTPS works ...in a comic! 🌈 🎉 🍕 Have you ever wondered why a lock icon appears on your browser URL bar? And why is it important? We did too, and this comic is for you! Follow the adventures of Certificat, Browserbird, and Compugter as they explain why HTTPS is crucial for the future of the web and how it all works together. Don't let the bad crabs get you (you'll know what we mean in the c
Cookieにかわる Sec-HTTP-State ヘッダの提案 - ASnoKaze blog
20190424 追記 IETFに提案仕様が提出されました https://tools.ietf.org/html/draft-west-http-state-tokens-00 Cookieの様々な問題を解決するために、Webセキュリティー界隈で活躍されるMike West氏から「Tightening HTTP State Management」というCookieに変わるHTTPにおいてステートを扱う仕組みが提案されています。 現在はIETFのHTTPbis WGのMLに投稿されただけで仕様が正式にinternet-draftとして提出されたものではありません。まだまだどうなるかは全然わからない状態です。 この提案では、現在のCookieはセキュリティと非効率性とプライバシーの問題があると言っています。 現在のcookieは、Same-Origin-Policyとは異なりオリジンを超えて
Resource Hintsでリソースを事前取得しよう！ - Qiita
Resource Hintsとは？ 下記4つのAPIから構成される。IEについては10以降にはなるが、大体のブラウザでサポートされている。 - DNS-Prefetch - Preconnect - Prefetch - Prerender 詳しくはResource Hints参照。 DNS-Prefetch ソーシャルボタンの設置やCDNの利用など、外部サイトからリソースを読み込む場合、「DNSルックアップ（ドメインをIPアドレスに変換すること）」が複数発生します。下記のように指定することで、あらかじめドメインの名前解決を行うことが可能です。 (function(document) { var servers = [ /* evernote */ "static.evernote.com" /* pocket */ ,"d7x5nblzs94me.cloudfront.net" ,"wi
Vary and the future of Cache Variation
マネージャー視点で考えるプロダクトエンジニアの評価 / Evaluating Product Engineers from a Manager's Perspective
Varyヘッダとキャッシュについて - 理系学生日記
さっき Cache-Control ヘッダの話を書いたんですが、もちろんキャッシュ制御に関しては Cache-Control ヘッダだけで収まる話ではなく、他にも多々のヘッダが影響を与えます。 その一つに、Vary ヘッダがあるので、今日はその話でも。 Vary ヘッダ Vary ヘッダは、RFC7231 で定義されているヘッダです。 vary というと「変わる」という意味を持つ動詞ですが、Vary ヘッダはその名の通り、「どのヘッダによってコンテンツが変わったのか」を示すレスポンスヘッダです。 例えば、よくあるタイプのスマートフォン対応の 1 つとして、User-Agent ヘッダを見て、PC 用 HTML を返却するか、スマフォ用 HTML を返却するかを切り替える実装を良く見ます。 この場合、レスポンスヘッダに Vary: User-Agent ヘッダを付けるのが常套手段です。ちなみ
Make Your Site Faster with Preconnect Hints | Viget
Depending on the page and the network conditions, these round-trips can add hundreds of milliseconds of latency, or more. If you are requesting resources from several different hosts, this can add up fast, and you could be looking at a page that feels more sluggish than it needs to be, especially on slower cellular connections, flaky wifi, or congested networks. One of the the easiest ways to spee
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
サーバーサイドレンダリング不要論 - Qiita
サーバーサイドレンダリング、Isomorphic、Universal JavaScriptなどの言葉をよく見かけます。なるほどね、良さそうだね、外部公開するサービスを書くことがあったら挑戦してみたいね、Mithrilにもisomorphic-mithrilってのをがんばっている人がいるし、みたいなことを漠然と思っていたのですが、最近ASCII.jpのシステムコールプログラミングの連載を書いていて、あらためてHTTPの仕様を見返してみて、逆にサーバーサイドレンダリングをしない方がいいのではないか、と思い始めました。 追記(23:30): サーバーサイドレンダリングと書いていますがUniversal JavaScriptみたいな凝ったビューの更新の意味です。 サーバーサイドレンダリングの欠点 サーバーサイドレンダリングのメリットとしてあげられるのは次の2点です。 検索エンジンのクローラー向け
The Collaborative API Development Platform
Sleep well. Your APIs are AI-ready.An AI-native API collaboration platform for developers who never stop building. Test, debug and design any endpoint with MCP client support, AI-powered capabilities, and seamless local, git, or cloud workflows. Open-source and free tier:Git Sync for 3MCP ClientsUnlimited ProjectsUnlimited collection runnerFree HTTP, gRPC, GraphQL, Socket.io, WSS + SSENo account r
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - sindresorhus/got: 🌐 Human-friendly and powerful HTTP request library for Node.js
Deep HTTP Dive Through Aleph & Netty
GitHub - icyleaf/halite: 💎HTTP Requests Client with a chainable REST API, built-in sessions and middlewares.
GitHub - mamantoha/crest: HTTP and REST client for Crystal
Rethinking Web Performance with Service Workers
GitHub - dpogue/rails_server_timings: Server Timing headers for Rails apps
GitHub - ember-cli/ember-ajax: Service for making AJAX requests in Ember applications