新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog
新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等
Building Protocols with HTTP
Workgroup: HTTP Internet-Draft: draft-ietf-httpbis-bcp56bis Obsoletes: 3205 (if approved) Published: 22 March 2022 Intended Status: Best Current Practice Expires: 23 September 2022 Author: Building Protocols with HTTP Abstract Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new applicati
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編）
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編） Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 本記事では奥氏のセッションをダイジェストで紹介します。（本記事は「HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）」の続きです） サーバプッシュの
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編） Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 奥氏はHTTP/3に対応したHTTPサーバ「H2O」の開発を行うだけでなく、IETFでHTTP/3の標準策定にも関わるなど、日本においてもっともHTTP/3に詳しい人の一人であるといえます。 本記事では奥氏のセッションをダイジェストで
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 ワーキング
WebPackaging の Signed HTTP Exchanges | blog.jxck.io
Intro WebPackaging は以下の 3 つの仕様を組み合わせたユースケースである。 Signed HTTP Exchanges: Signing (コンテンツに署名する) Bundled HTTP Exchanges: Bundling (コンテンツを 1 つにまとめる) Loading Signed Exchanges: Loading (そのコンテンツをロードする) 本エントリでは、各仕様を Signing/Bundling/Loading と記す。 現状、 Signing および Loading の仕様策定が進んでおり、 Chrome は Experimental な実装を行っている。 全体的に仕様が大きく、今後も変更される可能性が高いため、今回は実装が進んでいる Signing に絞り、ユースケース、仕様、および本ブログへの適用を中心に解説する。 Signing (Si
HTTP/3 や QUIC はまだ早すぎる
フューチャーアドベントカレンダー2018](https://qiita.com/advent-calendar/2018/future)のピンチヒッターです。ワイキキの海を見下ろすホテルからこんばんわ。 QUICがリブランドされて... 渋川の記事の補足というか、実装者目線からみた話を書きます。 立ち位置仕様策定には関わっていません。あくまで出てきた仕様を実装する実装者（Implementor) です。 また HTTP/3 や QUIC がメインというよりかは WebRTC がメインです。WebRTC が利用しているプロトコルが QUIC に置き換わる流れがきているため、QUIC を実装しており、さらに QUIC を利用したプロトコルとして、まずは HTTP/3 が採用されていることから、HTTP/3 に手を付けている状況です。 現時点では Chrome Canary M74 で利用可能な
私のURLはあなたのURLとは違う : curl作者の語る、URLの仕様にまつわる苦言 | POSTD
1996年にcurlプロジェクトの先駆けとなるhttpgetを始めたとき、私は初めてURLパーサを書きました。当時はまだ、ユニバーサルアドレスは URL : Uniform Resource Locators と呼ばれていました。その仕様は1994年にIETFによって発行されたものでした。この”URL”という用語からインスピレーションを得てツールとプロジェクトに命名したのが curl でした。 URLという用語は後に事実上、 URI : Uniform Resource Identifiers (2005年発行)に変わりましたが、「オンラインでリソースを指定する文字列のための構文と、そのリソースを得るためのプロトコル」という、基本的な点は変わりませんでした。curlでは、この構文仕様RFC 3986の定義に従う”URL”を許容するとうたっていますが、それは厳密には正しくありません。その理由
Requests: 人間のためのHTTP — requests-docs-ja 1.0.4 documentation
Requests: 人間のためのHTTP¶ リリース v1.0.4. (Installation) Requestsは、人が使いやすいように設計されていて、Pythonで書かれている Apache2 Licensed ベースのHTTPライブラリです。 Pythonの標準の urllib2 モジュールは、必要とされるほとんどのHTTPの機能を備えていますが、APIがまともに 使えません 。 様々なウェブ用途に合わせて作られていて、何回も修正されてきました。 簡単なことを行う(メソッドの上書きでさえ)のに、 かなり の量の作業が必要になります。 それはPython的ではないので、そんなに複雑にするべきではありません。 >>> r = requests.get('https://api.github.com/user', auth=('user', 'pass')) >>> r.status_c
Gixy - nginxの設定ファイルを静的解析して改善提案
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました HTTPサーバとしてnginxを使っているケースは多いかと思います。しかし設定に関する情報はまだまだ多くはなく、動くように設定はしても、それがベストなのかどうか判断できない方も多いのではないでしょうか。 そんな方にお勧めなのがGixyです。nginxの設定ファイルを解析して改善案を提示してくれます。 Gixyの使い方 Gixyのインストールは pip でできます。 pip install gixy 後はnginxの設定ファイルを指定するだけです。 $ gixy /path/to/nginx.conf ==================== Results =================== Problem: [host_spoofing] The proxied Host h
3.1.2 変数、値、文字列 / Nginx 入門
nginx では、コメントは頭に # をつけます。コメントは、ディレクティブ の後から# をつけても構いません。 nginx では、変数は頭に $ が置かれる。nginxでは非常に多数の変数が 用意されており、例えばHTTPの要求ヘッダの値にアクセスできるように $http_host 変数のような要求ヘッダのHostの値や、それが設定 されていない場合に備えて servername 変数、クライアントのIPアドレスがセット されている $remote_addr、あるいは応答メッセージのヘッダへ アクセスするために、例えば $sent_http_keep_alive 変数などがある。 値は、数値と文字列がありますが、数値に関しては以下の略記号が使える ようになっています。
HTTP/2時代のウェブサイト設計
CEDEC2021 ダウンロード時間を大幅減！～大量のアセットをさばく高速な実装と運用事例の共有～ SEGADevTech
HTTPライブストリーミングの概要 (TP40008332 0.0.0)</title> <meta name="Author" content="Apple Inc."> <meta name="Creator" content=""> <meta name="Producer" content="XEP 4.9 build 20070115"> <meta name="CreationDate" content=""> </head> <body>
HTTPライブ ストリーミングの概要 目次 概要 5 概要 6 特別なサーバソフトを使用しないオーディオとビデオの送信 7 オプションの暗号化を使用したオンデマンドのライブストリームまたはビデオの送信 7 お読みになる前に 7 関連項目 8 HTTP Streamingのアーキテクチャ 9 概要 9 サーバコンポーネント 11 メディアエンコーダ 11 ストリームセグメンタ 11 ファイルセグメンタ 12 メディアセグメントファイル 12 インデックスファイル（プレイリスト） 12 ディストリビューションコンポーネント 13 クライアントコンポーネント 14 HTTP Live Streamingの使用 15 ツールのダウンロード 15 メディアストリームセグメンタ 15 メディアファイルセグメンタ 15 メディアストリームバリデータ 16 バリアントプレイリストクリエータ 16 メタデ
Adobe Flash Media Server 4.5 * Flash Media Server アーキテクチャ
Adobe Flash Media Server アプリケーションはクライアントサーバーアーキテクチャを採用しています。クライアントコードは ActionScript（1、2、または3）で記述され、Adobe Flash Player 6 以降および Adobe AIR 1 以降で実行されます。Flash Media Server はメディアを iOS デバイスなどの Apple HTTP Live Streaming クライアントにストリーミングすることもできます。 サーバーコードはサーバーサイド ActionScript で記述されます。これは、ActionScript 1.0 に類似しています。 リアルタイムメディアサーバーFlash Media Streaming Server は、ライブ、VOD（ビデオオンデマンド）、livepkgr（HTTP ストリーミング）およびマルチキャス
QUICの仕様(ドラフト)が公開されたので、概要を読む - ASnoKaze blog
新しい仕様の翻訳を公開しました(2018/10/31) QUICの仕様を翻訳していく http://d.hatena.ne.jp/ASnoKaze/20160725/1469374715 2018年追記 最新の状況、概要についてはこちら asnokaze.hatenablog.com QUICの仕様(ドラフト) 5月頃に、Googleのブログでも「Google の試験的トランスポート、QUIC のアップデート」という記事で紹介されたように、QUICというUDPを用いたプロトコルが注目を集めています。 幾つかのドキュメントは存在していたものの、仕様としては未公開でした。 しかし、6/17に2つのInternet-Draftが公開されました 「QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2」 「QUIC Loss Recov
Node.jsのhttp.request関数/http.get関数とタイムアウト - hylom's
Node.jsのhttpモジュールには、HTTPクライアント機能も実装されている。http.request関数およびhttp.get関数がそれだ。詳細はドキュメントを確認していただきたいが、http.requestは任意のリクエストメソッドを使ってリクエストを送信できるものだ。また、http.getはGETリクエストに限定されるものの、URLを与えるだけで簡単にリクエストを送信できる。 たとえば以下のコード（http-request.js）は、引数で指定したURLに対しGETリクエストを送信し、取得したコンテンツを表示するものだ。 http-request.js #!/usr/local/bin/node var http = require('http'); // check arguments if (process.argv.length < 3) { process.exit(-1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP API の設計方向
HTTPパケットキャプチャあれこれ - Qiita
TCP＋TLSに代わる高速プロトコル、Google生まれの「QUIC」の特徴と標準化の行方【IETFトピックス2016-17】
インターネットにおける動画配信の仕組み
