キャッシュサーバの効率を改善するHTTP Variantsという提案仕様 - ASnoKaze blog
HTTP Variants IETFのHTTP WGやQUIC WGのチェアをしているmnot氏より、キャッシュの効率が改善する「Variants」というHTTPレスポンスヘッダを定義する「HTTP Variants」という提案仕様が出ています。 この機能は、Fastly VCLの機能の標準化のようです。 少々想定している背景がわかりづらいのですが、自分なりに簡単にまとめてみる。 背景 Webにおいて、サーバはクライアントからのリクエストヘッダを見てコンテンツを出し分けています。 例えば、Accept-Languageリクエストヘッダを見てコンテンツの言語を変更しています。キャッシュサーバももちろんこのAccept-Languageを見て、それぞれ毎にコンテンツをキャッシュする必要があります。 次の例を見てみましょう 1. ブラウザは下記のHTTPリクエストを送信する GET /foo H
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
Apply instant loading with the PRPL pattern | Articles | web.dev
Apply instant loading with the PRPL pattern Stay organized with collections Save and categorize content based on your preferences. PRPL is an acronym that describes a pattern used to make web pages load and become interactive, faster: Preload the late-discovered resources. Render the initial route as soon as possible. Pre-cache remaining assets. Lazy load other routes and non-critical assets. In t
XSSを防ぐ新しいXSS-Protectionヘッダ - ASnoKaze blog
evalとreportOnlyについて追記しました (2016/10/10) 2016/10/20 仕様名は以下の通りになりました。Anti-XSS Response-Time Uniqueness Requirement また、ヘッダ名は、XSS-Protectionヘッダではなく、ARTURヘッダとなっておりますが、また変更される可能性があります。 Googleの調査によると、CSPによるXSSの防止は現実的にデプロイの欠陥によりXSSの防止効果がないことを示しています。調査は「CSP Is Dead, Long Live CSP!」としてACMのカンファレンスで発表され、ペーパーも閲覧することができます。 9月に行われたW3C TPAC 2016のWebAppSecのミーティングで議論され、GoogleのMike West氏より新しくXSS Protectionという仕様が提案されて
httpoxy
Recommended reading Summary What Is Affected Immediate Mitigation Prevention Interesting, but once you’ve mitigated How It Works Why It Happened History of httpoxy CVEs A CGI application vulnerability (in 2016) for PHP, Go, Python and others httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. It comes down to a simple namespace conflict: RFC 3
Real–world HTTP/2: 400gb of images per day - 99designs
The now–finalized HTTP/2 specification has rightfully garnered a lot of interest from the web performance community. The new protocol is aimed at addressing common network performance issues with the aging HTTP/1.x protocol, whilst preserving the existing semantics. We began a small-scale rollout for static assets earlier this year. After building confidence in our new infrastructure, we began tra
Choosing an HTTP Status Code - Racksburg
What could be simpler than returning HTTP status codes? Did the page render? Great, return 200. Does the page not exist? That’s a 404. Do I want to redirect the user to another page? 302, or maybe 301. I like to imagine that HTTP status codes are like CB 10 codes. “Breaker breaker, this is White Chocolate Thunder. We’ve got a 200 OK here.” — Aaron Patterson (@tenderlove) October 7, 2015 Life is bl
Feature Policy、ブラウザの特定機能を無効にする仕様 - ASnoKaze blog
W3CでFeature Policyという仕様が議論されています。仕様は著者であるGoogleのIlya Grigorik氏のリポジトリ(URL)より確認できます。 このドキュメントはまだW3C公式のドキュメントとはなってはいませんが、先月行われたFace-to-Faceのミーティングでも議論がされています(議事録) Feature Policy セキュリティやパフォーマンスの観点で、Webデベロッパーがブラウザの特定のAPI（機能）を無効にしたい場合もあります。 そこで、 Feature-Policyヘッダを用いて以下のようにブラウザの機能を制限できるようにするのがこの仕様です。 また、このFeature-Policyヘッダは現在IETFで議論が行われている"A JSON Encoding for HTTP Header Field Values"(URL)というHTTPヘッダ値にjso
Mixed ContentのブロックされたURIをレポートさせる仕様追加 - ASnoKaze blog
Mixed Content Mixed Contentと言う仕様により、httpsで提供しているページの中でhttpで提供するリソース(script等)があるとそのリソースはブロックされます。 このMixed Contentには、Content Security Policyのblock-all-mixed-contentディレクティブも定義されています Content-Security-Policy: block-all-mixed-content このディレクティブは、scriptなどのBlockable Contentだけでなく、画像や動画といったOptionally-blockable Contentもブロックするようにするためのディレクティブです。 このblock-all-mixed-contentの仕様にレポート機能が追加された模様(間違い等あればご指摘下さい violatio
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 Problem Details for HTTP APIs Abstract This document defines a "problem 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
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
On HTTP Load Testing
Hi, I’m Mark Nottingham. I write about the Web, protocol design, HTTP, Internet governance, and more. This is a personal blog, it does not represent anyone else. Find out more. Comments? Let's talk on Mastodon. @mnot@techpolicy.social other HTTP posts Yet More New HTTP Specs Wednesday, 8 June 2022 A New Definition of HTTP Monday, 6 June 2022 How Multiplexing Changes Your HTTP APIs Sunday, 13 Octob
The Collaborative API Development Platform
Announcing Kong Insomnia 9.3 with after-response scripting, global environments, folder-level configuration, and more. Design, debug, test, and mock APIs locally, on Git, or cloudBuild better APIs collaboratively for the most popular protocols with a dev‑friendly UI, built-in automation, and an extensible plugin ecosystem. Get Started for Free
LWSとHTTPヘッダインジェクション | 技術者ブログ | 三井物産セキュアディレクション株式会社
今回のトピックは「HTTPヘッダインジェクション」です。 HTTPヘッダインジェクションは、リクエストパラメータの操作等により、HTTPのレスポンスヘッダに改行文字（CR,LF）を挿入し、ヘッダフィールドを追加したり、ボディを操作したり、新たな偽のHTTPレスポンスを作り出したりする（HTTPレスポンス分割）攻撃、あるいは脆弱性です。 状況にもよりますが、この脆弱性は、被害者のブラウザにおいて、脆弱性のあるページのオリジンで不正なJavaScriptを実行する攻撃につながりえます。つまり被害としては、クロスサイトスクリプティングと同様になりうるということになります。 この脆弱性は古くから知られており、近年は特に目新しいトピックもなかったのですが、2014〜2015年に状況の変化があったので、今回取り上げてみたいと思います。 タイトルにあるように、本記事の主なテーマは「LWS」とHTTPヘッ
Please. Don’t Patch Like That.
Modifying HTTP resources is not a new topic. Most of the existing HTTP or REST APIs provide a way to modify resources. They often provide such a feature by using the PUT method on the resource, asking clients to send the entire resource with the updated values, but that requires a recent GET on its resource, and a way to not miss updates between this GET call, and the PUT one. Indeed, one may upda
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発者を苦しめる.NETのHttpClientのバグと紛らわしいドキュメント
HTTP API の設計方向
GitHub - alash3al/xerver: a tiny static and fastcgi reverse proxy written in golang
GitHub - valyala/fasthttp: Fast HTTP package for Go. Tuned for high performance. Zero memory allocations in hot paths. Up to 10x faster than net/http
もしWebセキュリティのエンジニアがRFC7540の「HTTP/2アプリ」をWeb診断したら
