GETでもPOSTでもない HTTP新メソッド「QUERY」が標準化へ
GETでもPOSTでもない、第3のHTTPメソッドが標準化に進んだ。IETFが公開した「QUERY」は、検索専用のHTTPメソッドとして設計され、長年指摘されてきたURL長や検索APIの課題を解決することを目指す。新仕様の仕組みと実装への影響を読み解く。 インターネットの運用や利用に関する技術仕様の標準化を推進する国際的な任意団体Internet Engineering Task Force（以下、IETF）は2026年6月、HTTPの新たなリクエストメソッド「QUERY」の仕様を定義した技術文書「RFC 10008」を公開した。 RFC 10008は、将来的な正式標準を目指す「Proposed Standard（標準候補）」として位置付けられており、WebブラウザやWebサーバ、APIフレームワークなどでの実装を見据えた仕様となる。 HTTPでは長年、「GET」と「POST」という2つの
HTTPが全てを飲み込む（前編）～HTTPの2層構造と、HTTP Semanticsとは何か？
Webを構成する重要な要素の1つであるHTTPは、その最新仕様で2層構造となり、バージョンに関係なく使えるSemanticsと、特徴の異なる通信仕様を定めたHTTP/1.1、2、3に分割されました。 さらに現在では、HTTPの上にあらためてUDPやIP、イーサネットなどのプロトコルを実装する提案が行われており、まさにHTTPは通信の全てを飲み込む勢いで進化しつつあります。 こうしたHTTPの最新動向の解説が、大手CDNベンダでエッジクラウドなども展開するFastlyが2023年11月8日開催したイベント「Yamagoya 2023」で同社シニアプリンシパルエンジニアの奥一穂氏が行ったセッション「HTTPが全てを飲み込む」にて行われました。 本記事ではこのセッションをダイジェストで紹介していきます。記事は以下の3つに分かれています。 HTTPが全てを飲み込む（前編）～HTTPの2層構造と、H
HTTPキャッシュを使いこなして、Webアプリを快適に(1) | IIJ Engineers Blog
セキュリティ本部 セキュリティ情報統括室に所属 システム開発者。2000年問題で「2038年問題は定年で対応しなくていい！」とフラグを...。 cats_dogs開発者のヒラマツです。 HTTPキャッシュをうまく使う技術、HTTPキャッシュ制御を解説します。 HTTPキャッシュは、WebアプリなどのWebサービスの通信を最適化する技術です。 HTTPのCache-Controlヘッダーの使い方の話でもあります。 HTTPキャッシュ制御と言っても、Cache-Controlヘッダーの設定だけなので、簡単そうに思えます。 しかし、正しく設定しようとすると、案外、複雑で苦労します。 また、理解なしに使うと、情報漏えいの問題を起こす可能性もあり、適当に設定するのは危険です。 ぜひ、この文章を読んで、理解した上で、Catch-Controlを設定してください。 cats_dogsの仕様を書くときに、
API設計まとめ - Qiita
はじめに 自分は2021年に新卒でWeb系の開発会社にフロントエンジニアとして入社し2022年で2年目になります。 実務ではReact×TypeScriptを利用したフロント周りとNode.js(Nest)やRailsを用いたバックエンド(API)の開発をしています。 その中で使っていたAPI設計について改めて学び直したのでまとめて行きます。 この記事の対象者 エンジニア初心者から中級者 APIについて学びを深めたい人 この記事の目標 APIについて学ぶ 我流ではなく正しいAPI設計について学ぶ この記事でやらないこと 具体的にコードを用いたAPI設計の書き方の説明に関しては下記の記事で解説をしています。 APIについて APIとは APIは"Application Programming Interface"の略で、直訳すると「アプリケーションを使プログラミングを使ってつなぐ」という意味
第1章 進化するHTTPの歩み ～ HTTP/1.1とHTTP/2をおさらいし、HTTP/3の基本を知る | gihyo.jp
HTTP/3入門 第1章進化するHTTPの歩み ～ HTTP/1.1とHTTP/2をおさらいし、HTTP/3の基本を知る この特集記事は2021年6月24日に発売されたWEB+DB PRESS Vol.123に掲載された特集1「HTTP/3入門」を再掲したものです。 先日2022年6月にHTTP/3を含むHTTP関連の仕様が正式なRFCとなりました。ここではRFCの正式リリースに伴い、いち早く変更点を抑え、囲みボックスを用いた加筆解説でわかりやすくお伝えしております。 特集のはじめに HTTP（Hypertext Transfer Protocol）の最新版であるHTTP/3が登場しました。HTTP/3では、より安全で速い通信が行えます。本特集では、今までのHTTPにあった課題と、HTTP/3で課題をどのように解決し、改善が行われたかを解説します。 本章では、HTTPそのものと各バージ
HTTP/3 の特徴 HTTP/2とQUICの違い | REDBOX Labo
今回は改めてHTTP/3とはどのようなもので、QUICとは何か、HTTP/2時代からの改善点と我々はHTTP/3の波に乗るべきなのかチェックしていきたいと思います。時がたち次世代Web通信プロトコル「HTTP/3」の標準化プロセスが完了し、2022年6月に「RFC 9114」となりました。既に基盤となる「QUICプロトコル」の標準化プロセスも完了し、RFC9000としてRFCとなりました。もうHTTP/3は無視出来ないところまできています。 HTTP/3の誕生と歴史HTTP/3とは、HTTP/1.1 HTTP/2に続く新しいバージョンの約束事です。HTTP/1.1からHTTP/2は様々な点で劇的な進化を遂げましたが、HTTP/3はHTTP/2の根本的な課題をTCP・TLSの融合という形で解決し問題点を補うよう進化してきました。 1991年：HTTP/0.9（HTTPの始まりGETメソッドし
HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io
Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field
『くいっく』HTTP/3編 RFC対応版 - 猫耳堂 - BOOTH
●HTTP/3って何？ HTTP/2 の弱点を克服することができるHTTPの最新バージョンです その他、ネットワークの切り替わり時にもコネクションを維持できたり、ハンドシェイク時の通信回数が削減されていたりと様々な機能のアップデートが入っています ●読む上であると良い知識 ハンドシェイク等のTCPの基本をなんとなくわかっている方が望ましいです パケットロスや暗号化等のネットワークの基礎知識もほんのりあると理解が深まります HTTP/2の知識はまったくもって不要です ●本書で取り扱う範囲 HTTP/2の特徴と弱点 HTTP/3の仕組み ●本書の内容 Chapter1. HTTP/2のおさらい Chapter2. HTTP/2の問題点 Chapter3. HTTP/3を学ぼう Chapter4. HTTP/3の問題点 ●こんな人にお勧め HTTP/3の概要や機能を一通り抑えておきたい人 新しい
HTTP/3が正式に勧告、脱TCP時代の幕開けか
インターネット関連技術の標準化を手掛けるIETF（Internet Engineering Task Force）は2022年6月6日（米国時間）、通信プロトコル「HTTP/3（HyperText Transport Protocol/3）」を「RFC 9114」として勧告した。HTTP/3はインターネット通信の多くを占めるWebにおける通信プロトコルの最新版である。 最大の特徴は、トランスポートのプロトコルに「QUIC（Quick UDP Internet Connections）」を採用した点。QUICは2021年にIETFで「RFC 9000」として勧告された。その名前が示すように、TCP（Transmission Control Protocol）ではなく、UDP（User Datagram Protocol）に基づくプロトコルだ。TCPが備えていた再送制御の仕組みや、TLS（Tr
Googleが設計した次世代通信プロトコル「QUIC」とは？
プライム・ストラテジー「KUSANAGI」の開発チームの石川です。 「KUSANAGI」はWordPressをはじめとするCMSを高速に動作させる世界最速クラスの仮想マシンです。わたしたちは「KUSANAGI」を開発して皆様にご利用いただくほか、お客様のウェブサイトを「KUSANAGI」で運用しています。 この連載では、「KUSANAGI」の開発やお客様とのお話の中で感じた課題や実際の運用の中で得た知見などをお伝えしています。 今回は次世代のHTTPとも呼ばれる「HTTP/3」の裏側で使われている「QUIC(クイック)」についてお話ししたいと思います。 Googleが通信パフォーマンス改善について追求した「QUIC」 QUICはもともとGoogleによって設計されたトランスポート層の通信プロトコルです。 Googleがプロトコルを開発することを意外に思う人がいるかもしれませんが、Googl
IETFによるHTTP/3の標準化プロセスが完了、「RFC 9114」に
IETFのQUICワーキンググループはHTTP/3の標準化プロセスを完了し、「RFC 9114」として発表しました。 HTTP/3 has been published as an RFC. https://t.co/jdsUHy9FKD — IETF QUIC WG (@quicwg) June 6, 2022 HTTPはWorld Wide Webを開発したティム・バーナーズ＝リーによって1990年に最初のバージョンが作られました。 その後、1996年にHTTP/1.0がIETFによってRFC化され、1999年にHTTP/1.1へアップデート。2015年2月には初めてのメジャーバージョンアップとなるHTTP/2がRFCとなりました。HTTP/3は7年ぶりのメジャーアップデートと言えます。 HTTP/3では高速な通信を実現するために、HTTPのトランスポート層を従来のTCPからQUICに
rjとtとjqコマンドでHTTPレスポンスを試験する - ゆーすけべー日記
Web 開発者は HTTP レスポンスをよく見る。 以前 CDN を導入する際に、キャッシュがヒットしているかどうか、どこのエッジがキャッシュを返しているかを確認するためにヘッダをよく見ていた。また、ヘッダだけではなく、TTFB といったレスポンスタイムも気にしている。とにかく HTTP レスポンスをよく見る。 HTTP レスポンスを確認する３つの方法 Chrome さえあれば DevTools を見て一目瞭然である。 とはいえ、コマンドラインで確認したい時がしばしばある。 GUI を操作するよりも手軽である。 その場合はcurlコマンドを叩けばよい。 これでプロトコル、ステータス、ヘッダが分かる。 また、レスポンスタイムを測りたければ、その名もttfb.shというcurlをラップしたコマンドラインツールがある。 https://github.com/jaygooby/ttfb.sh この
net／httpでつくるHTTPルーター 自作入門
Golangの標準パッケージであるnet/httpを使ってHTTPルーターを自作する話です。 表紙は新書メーカーさんで作成しました。 https://yubais.net/tools/paperback-maker/ 追記： 要約版をqiitaに書いてあります。手短に知りたい場合はこちらが良いかもしれません。 https://qiita.com/bmf_san/items/312fac5b3132d8bee4ca 自作ルーターがawesome-goにリストアップされました :D https://github.com/avelino/awesome-go#routers 追記： コードのハイライトを修正しました。 追記： Go Conference 2021 Autumnで"net/httpでつくるHTTPルーター自作入門"というタイトルで発表しました。 https://speakerdec
QUICをゆっくり解説(2)：ネゴせよ | IIJ Engineers Blog
仕事のテーマは、DNSサーバの実装。Haskellコミュニティではネットワーク周りを担当しています。2022年に正社員から契約社員となって故郷の山口県に移住し在宅勤務。ときどき東京本社にいます。最近の趣味は、瀬戸内で美味しい魚やイカを釣ること。 QUICへの誘導 前回のブログで、ブラウザが HTTP/3 (HTTP over QUIC) に対応したサーバにアクセスしたときに、最初は HTTP/2 を使い、2回目の通信からHTTP/3を使うようになると説明しました。今回は、この過程でクライアントとサーバが何を折衝しているか、以下の順で解説します。 TLSのバージョン HTTPのバージョン HTTP/2からHTTP/3への誘導 QUICのバージョン TLSのバージョン あるURLで指定されたサーバにクライアントがアクセスすることを考えます。URLは、httpsで始まっていたとしましょう。つまり
HTTP検索条件、GETにするか？POSTにするか？ | フューチャー技術ブログ
はじめにTIG DXユニット 1真野です。 RESTfullとかRESTishな方針でWebA PIの横断検索を設計する際にチーム内で方針について議論したやり取りの備忘記事です。 注意としてB2C向けなWeb APIを提供するというよりは、主に企業間または企業内部で使われるようなAPIの設計のバイアスがあります。LSUDs（Large Set of Unknown Developers）かSSKDs（Small Set of Known Developers）で言えば、確実にSSKDs脳で記事が書かれています。 REST API広く使われているため日本語記事も多数です。実践RESTful HTTP - InfoQ や、0からREST APIについて調べてみた など良さそうな記事が沢山でてくるの読むと良いでしょう。一般的な設計方法はやや古いですがWeb API: The Good Parts
ChromeでHTTP/3サーバーをlocalhostに立てて自己証明書を信頼させてもHTTP/3通信できない + 解決策 - nwtgck / Ryo Ota
HTTP/3をするにはhttpsをする必要があるため証明書を作る。だがそれを信頼させてもHTTP/3ではなくHTTP/1.1にフォールバックした。（HTTP/2にならないのは使ったライブラリの使い方の関係だと思う。）
HTTPキャッシュ入門の入門 – cat /dev/random > /dev/null &
ローカル・経路上のキャッシュを併用しよう キャッシュは再利用されるほどいいものです。 サイトの規模にもよるのですが、ローカルと経路上のキャッシュはそれぞれ性質が異なるため、ブラウザキャッシュだけ適切に設定しておけば経路上では不要というわけではありません。 ローカルキャッシュはキャッシュを持つクライアント自身がサイトを再訪する場合は有効ですが、キャッシュを持っていない新規クライアントには無効です。 経路上のキャッシュは新規クライアントに対してもキャッシュを返すことができるため、例えばサイトへの流入が突然増えるといった事態でも対処がしやすいです。 そのためコンテンツ次第ではありますが、ブラウザキャッシュのように特定のクライアントでしか使えないprivate cacheにするよりも、 効率を考えてローカル・経路上のどちらでもキャッシュができ、多数のクライアントで共有できるshared cache
Webページがブラウザに表示されるまでに何が起こるのか？
## # Host Database # # localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 localhost 上記で「127.0.0.1 localhost」とあるように、[IPアドレス] [ホスト名]というフォーマットで書かれます。 HOSTS.TXTが使われていた当時 ( 1970年代 ) では、わずか数百台のホストしかなかったので、ネット上の全てのホスト情報の記載が可能でした。 しかし、インターネットが普及していくにつれてHOSTS.TXTは肥大化していき、1983年には、ホスト数はおよそ数万台になりました。もはやHOSTS.TXTによる名前解決は不可能となったので、現在のようなDNS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TLS, HTTP/2演習
【図解】https(SSL/TLS)の仕組みとシーケンス,パケット構造 〜暗号化の範囲, Encrypted Alert, ヘッダやレイヤについて～
