[B! http][RFC] ButterflyFishのブックマーク

The Signature HTTP Authentication Scheme

ButterflyFish 2024/04/18

リンク

A New Definition of HTTP

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 How Multiplexing Changes Your HTTP APIs Sunday, 13 October 2019 Designing Headers for HTTP Compression Tuesday, 27 November 2018 How to Think About HTTP S

ButterflyFish 2022/06/08

http
RFC

リンク

HTTPのバージョンについて、現在のまとめ - Qiita

はじめに HTTPのバージョンと仕様について、個々最近の動きについて整理しておこうかと思います。 HTTPには幾つかのバージョンが有り、現在HTTP/1.1とHTTP/2が広く利用されており、HTTP/3も徐々に使われだしています。バージョンが異なっていても、クライアントからHTTPリクエストを送り、サーバがHTTPレスポンスを返すのは変わりません。HTTPメッセージをどのようなフォーマットで送るかはバージョンによって異なりますが、HTTPメッセージが持つ意味は変わりません。意味(セマンティクス)とは、GETリクエストやPOSTリクエスト、ステータスコード、ヘッダがどういった意味を持つかということです。バージョンと、セマンティクスの歴史的遷移は下記のとおりです。 HTTP/1.1とセマンティクス HTTPは最初0.9から始まり、HTTP/1.0、HTTP/1.1と進んできました。 H

ButterflyFish 2021/03/22

リンク

"HTTPヘッダ"が指すものとは - Qiita

普段"HTTPヘッダ"と呼んでるものについて、仕様上は "header fields" と呼ぶらしかったり、自分でも整理できていなかった。今後もHTTP関連の仕様を読んでいく上でも理解しておきたかったので、この記事では、下記の用語について整理していく HTTP field header/trailer field field line HTTP セマンティクスまず、参照するドキュメントについて簡単に補足します。今回触れる用語は、HTTPセマンティクスの仕様である「HTTP Semantics(ドラフト版)」で定義されています。 HTTPセマンティクスとは、HTTPメッセージ(HTTPメソッドや、レスポンスコード、フィールド)の意味の定義です。各HTTP/1.1~HTTP/3の仕様ではこのHTTPメッセージをどのように送るか(例えば、HTTP/2ではストリーム上のフレームで送信する)を

ButterflyFish 2021/02/09

http
RFC

リンク

HTTP 418ステータスコードが予約される - ASnoKaze blog

「418 I’m a tea pot」としてよく知られる 418 ステータスコードについて、IETF HTTPbis WGで議論になっていました。「418 I’m a tea pot」はジョークRFCである「RFC2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)」で定義されているステータスコードです。ここで注意するのは、418はHTCPCPで定義されているステータスコードであり、HTTPで定義されているステータスコードではないという点です。この議論については以前 Qiita で書いたとおりです。 qiita.com HTTPで418ステータスコードを予約以前このブログで書いたとおり、HTTPセマンティクスに関して仕様の再改定が行われております asnokaze.hatena blog.com その後、3つの仕様に分割され

ButterflyFish 2018/10/23

http
RFC

リンク

RFC 7807: Problem Details for HTTP APIs

Internet Engineering Task Force (IETF) M. Nottingham Request for Comments: 7807 Akamai Category: Standards Track E. Wilde ISSN: 2070-1721 March 2016 Probl em Details for HTTP APIs Abstract This document defines a "probl em detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. Status of This Memo This is

ButterflyFish 2018/10/14

リンク

RailsでHTTP APIのエラーレスポンスを "problem detail" 形式で返却する - Qiita

Web API開発において、エラーをどういう形式で返却するか、というのは設計する際の悩みポイントかもしれません。エラーレスポンスの仕様の1つとして RFC7807 Probl em Details for HTTP APIs があります。この形式をサポートしつつ Rails や Sinatra でも使える Ruby ライブラリをこの度作りましたのでそのご紹介。その名も Probl emDetails. 本記事では Rails での使い方について。 Probl emDetailsの機能概要 gem では以下の機能をサポートしています。 RFC7807形式を実装したオブジェクトクラス Railsサポート: probl em detail 形式でレスポンスする probl em renderer Sinatraサポート: probl em render function probl em details 形