User-Agent が使えなくなる世界線で何を考えたら良いだろう - Qiita
※ この記事は 2021/03 時点での情報になり、今後大きく変動する可能性があります。 User-Agent が Google Chrome で凍結・非推奨になる という話題が年明け以降一部の界隈で盛り上がっています。 また、Chrome に限らず、 Firefox, Safari など Chromium 以外のベンダでも User-Agent（以下 UA） の凍結・非推奨が予想されており、近い将来 UA を使わずにデバイスの判定をする世界線は避けて通れなくなりそうです。 UA の代替となる指標 Google は UA を凍結・非推奨とする代わりに User-Agent Client Hints (以下 UA-CH) を新たなデバイス等の判定の指標として提案しています。 ※ UA-CH は W3C の Draft Community なので、今後仕様が変わる可能性があります。 例えば C
Referrer-Policy - HTTP | MDN
HTTP ガイド リソースと URI ウェブ上のリソースの識別 データ URL MIME タイプ入門 よくある MIME タイプ www 付きと www なしの URL の選択 HTTP ガイド HTTP の基本 HTTP の概要 HTTP の進化 HTTP メッセージ 典型的な HTTP セッション HTTP/1.x のコネクション管理 プロトコルのアップグレードの仕組み HTTP セキュリティ Content Security Policy (CSP) HTTP Strict Transport Security (HSTS) Cookie security X-Content-Type-Options X-Frame-Options X-XSS-Protection Mozilla web security guidelines Mozilla Observatory HTTP アク
HTTPと硬直化 (ossification) の問題 - ASnoKaze blog
「硬直化(ossification)」はあまり聞き慣れない言葉だが、インターネットやWebの通信において問題となってきています。 新しい機能の展開を阻害するこの問題は、HTTPにおけても問題になっておりましたが、HTTPの標準化を行うIETFで動きがありました。 IETFのHTTP WGではオープンレターとして「HTTP and Web Application Firewalls: Managing Ossification Risk」を公開し、WAFベンダと連携してこの問題に取り組んでいく意思が示されています。 この事に関して簡単に説明していきます 目次 硬直化(ossification) とは HTTPにおける 硬直化(ossification) グリス (GREASE)の例 HTTPにおけるGREASE 硬直化(ossification) とは 「硬直化(ossification)」
自由研究：フィード巡回ボットのHTTPリクエスト観察日記 | feedforce Engineers' blog
夏の自由研究を9月頭に行ったので、その経過などをここで発表したいと思います。 １日目 フィードを巡回するボットが、どんなHTTPリクエストを行っているのか気になったので、HTTPリクエストのログを記録することにしました。 これから、ログを観察していこうと思います。 - どんなHTTPリクエストをしているのだろう？ - 知らないHTTPリクエストヘッダとかあるかな？ - 対応できていないHTTPリクエストヘッダとかあるかな？ ログを記録には、簡単なPHPスクリプトを使います。 - CGIで動作しているので、$_SERVER['HTTP_*']からHTTPリクエストヘッダを抽出します - スクリプトは最終的にフィードを返します - そのほか、必要に応じて修正していきます 巡回してもらうために、いくつかのフィードリーダーに登録しました。 - Google Reader - はてなRSS - Li
HTTP/3の解説を書いた (2020/06/01) - ASnoKaze blog
@flano_yukiがHTTP/3について書きました。(無料です。 2020年6月時点の内容となっています。概ねQUICやHTTP/3の大枠は固まっており、2021年の内容と照らし合わせても、大きな変更はありません。PDFを下に貼ってあります。 , (宣伝) また、2021年6月にアップデートも含め、WEB+DB PRESS Vol.123に記事を書かせていただいております（有料） gihyo.jp http3-note https://github.com/flano-yuki/http3-note にPDFを置きました 1. はじめに(HTTP/3と概要) 2. QUICについて 3. HTTP/3について 4. HTTP/3 拡張仕様と応用 5. (執筆予定) 実装、ツール紹介 公開形式は、そのうちなんとかするかも 内容 1. はじめに(HTTP/3と概要) 1.1 はじめのはじめ
GitHub - flano-yuki/http3-note: My HTTP/3 Note
1. はじめに(HTTP/3と概要) 1.1 はじめのはじめに 1.2 HTTPのセマンティクスとバージョンの話 1.3 HTTP/3の概要 1.4 HTTP/3 と呼ばれるまでの道のり 1.4.1 Google QUICの実験 1.4.2 HTTP over QUIC、標準化の開始 1.4.3 HTTP/3への改称 1.5 標準化動向を追うために 2 QUICについて 2.1 QUIC、はじめに 2.2 QUICの概要 2.3 QUICコネクションとQUICパケットの基礎 2.4 フレームについて 2.5 ストリームについて 2.6 コネクションの確立 2.7 コネクションのクローズ (TODO)2.8 負荷分散・トラフィックのオペレーション 2.9 その他 (FEC, Multipath, LB) 2.9.1 Forward Error Correction(FEC) 2.9.2 MP
HTTP Security Headers - A Complete Guide
SECURITY IS AWESOME SECURITY IS AWESOME I write about security and privacy. I regularly post original security research, custom tools, and detailed technical guides. Companies selling "security scorecards" are on the rise, and have started to become a factor in enterprise sales. I have heard from customers who were concerned about purchasing from suppliers who had been given poor ratings, and in a
Apache HTTP Web Server 2.4.33公開 - 脆弱性を修正
JPCERTコーディネーションセンター(Japan Computer Emergency Response Team Coordination Center:JPCERT/CC)は3月27日、「Japan Vulnerability Notes(JVN)」に掲載した記事「JVNVU#95818180: Apache HTTP Web Server 2.4 における複数の脆弱性に対するアップデート」において、Apache HTTP Web Server 2.4の脆弱性について伝えた。 脆弱性の影響を受けるプロダクトおよびバージョンは次のとおり。 Apache HTTP Web Server 2.4.33よりも前のバージョン JVNVU#95818180 - Apache HTTP Web Server 2.4 における複数の脆弱性に対するアップデート 上記のバージョンでは、7つの脆弱性(CV
とまれーっ うごけーっ - Qiita
深夜にTwitterでGuzzle(PHPのHTTPクライアントライブラリ)がPromises/A+(日本語訳)のインターフェイスを持ってるって話が出てたので、深夜のテンションでサンプルコードを書いたらこうなった。 とまれーっ うごけーっ pic.twitter.com/8stozzrSyb — ぞぬのフレンズ (@tadsan) February 9, 2017 あと、わーい、すごーいの便乗。 <?php include_once getenv('HOME') . '/.composer/vendor/autoload.php'; use GuzzleHttp\Client; $client = new Client(['allow_redirects' => ['on_redirect' => function () { throw new \Exception(); }]]); $k
HTTPS、トラフィックの50%を突破
2月1日(現地時間)、Threatpostに掲載された記事「HTTPS Hits 50 Percent Traffic Milestone｜Threatpost」が、Mozilla Firefoxブラウザが実施した2週間にわたるデータ調査の結果、HTTPS通信の平均値がトラフィックの50%を超えたと伝えた。2016年の段階でHTTPSの通信量が50%を突破したことが観測された時期があるが、今回は2週間にわたる調査の結果としており、着実にHTTPS通信が普及していることが示された結果となった。 記事ではこうした結果が得られた背景として、通信量の多くがTwitter、Facebook、Gmailといった少数のプレーヤーに依存しており、こうしたプレーヤーがHTTPSによる通信を採用していることや、主要Webブラウザが安全なHTTPS通信を意識させるような警告メッセージを出すようにすることでHTT
HTTP の新しいステータスコード 103 Early Hints | blog.jxck.io
Intro これは、 http2 Advent Calendar 2016 の 16 日目の記事である。 HTTP に新しいステータスコード 103 Early Hints が追加されようとしている。 HTTP/1.1 および HTTP2 双方と関わり、リソース配信の最適化に利用することができる。 いったい何のために必要なのか、どういうメリットが考えられるかを解説する。 HTTP2 Push の復習 まず HTTP2 の Push について復習する。 H2 Push は、簡単に言えば PUSH_PROMISE フレームを用いて、レスポンスよりも先に依存するリソースを返すための仕様である。 例えば /users のレスポンスは script.js と style.css をサブリソースとして含んでいるとする。 HTTP2 では SQL を発行して Users の一覧を取得している間に、先行し
やる気のステータスコード
200 やる気 OKやる気マンマンである201 やる気 Createdこれから本気出す202 やる気 Acceptedやる気があることだけは分かった204 やる気 No Content見せかけだけのやる気である400 やる気 Malformedそんなところにやる気を見せられても…401 やる気 Unauthorizedやる気あるのは分かったけど、誰だお前?403 やる気 Forbiddenお前はやる気になるな!404 やる気 Not Found今はやる気無くなっちゃった405 やる気 Method Not Allowedお前はやる気出すキャラじゃないだろう409 やる気 Conflictさっき、別のことの方がやる気あるって言うてたやん410 やる気 Gone探さないでください…413 やる気 Too Large恐ろしいやる気だ…付き合いきれん500 やる気 Internal Server
不正なSSL証明書を見破るPublic Key Pinningを試す - ぼちぼち日記
先日のエントリー 「TLSとSPDYの間でGoogle Chromeがハマった脆弱性(CVE-2014-3166の解説)」で予告した通り、今回不正なSSL証明書を見破る Public Key Pinningの機能について解説します。 Public Key Pinning は2種類の方法があります。あらかじめブラウザーのソースコードに公開鍵情報を埋め込む Pre-loaded public key pinning と、サーバからHTTPヘッダでブラウザに公開鍵情報を通知するHTTP-based public key pinning (HPKP)の２つです。 Chromeは既に両者の機能を実装済ですが、ちょうど近日リリースされる Firefox 32 の Stable バージョンから Pre-loaded public key pinning が実装されました。Firefox32リリース記念と
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
HTTPステータスコード451(政治的な検閲)が正式に承認される
mnot’s blog: Why 451? draft-ietf-httpbis-legally-restricted-status-04 HTTPステータスコード451がIETFで正式に承認された。近いうちにRFCとしても発行される。 元ネタは、Ray BradburyのFahrenheit 451(華氏451)というタイトルの小説で、これはディストピアな検閲社会を描いている。 451の意味は、403(禁止/権限がない)と似ているが、正確な意味は、ドラフトを引用すると、以下の通り。 このドキュメントはサーバーオペレーターが、あるリソース、あるいはあるリソースを含むリソース群に対し、閲覧を検閲するよう法的な命令を受け取った時に使うHypertext Transfer Protocol(HTTP)ステータスコードを規定するものである。 このステータスコードは、法律や一般大衆の雰囲気がサーバー
GitHub - facebook/proxygen: A collection of C++ HTTP libraries including an easy to use HTTP server.
5分でわかる正しい Web サイト常時 SSL 化のための基礎知識
Web サイトを常時 SSL 化する場合に、最低限知っておかなければならない知識や、注意点、実際の設定方法まで、ひと通りまとめてみました。メリットやデメリット、証明書の種別からリダイレクト設定などについても解説しています。 HTTPS をランキングシグナルに使用しますと Google が公式に発表したあたりから、Web サイトの SSL 対応、特に Google が推奨している Web サイトをすべて HTTPS で配信する、所謂 「常時 SSL 化」 についての話を聞いたり、実際にお客様から相談されたりするケースが増えてきました。 そこで、いい機会だしその辺に関する情報をまとめておこうかな～ と思って書いてみた、恒例の （？） 5分でわかるシリーズ。書き終わって見たところ絶対に 5分じゃ無理っていう文章量になっててどうしようかなぁとも思ったんですが、気にせず公開してみます。 常時 SSL
「通信の最適化」の論点 - めもおきば
論点書き出してみたけど多すぎて超絶カオス。 現状発生している実害 チェックサム比較の失敗(発端) 画質の劣化 exif等メタデータ削除による情報欠損 元ファイルよりサイズが増える 技術的詳細が非公開 「最適化」という単語の是非 オプトインとオプトアウト 送信者(コンテンツ提供者)の同意 自衛のために全HTTPS化することで、かえってトラフィック増える問題 HTTPS化による計算機コスト、ファイル改竄による不具合対応のリスクの負担 サービス内容の意図しない/再現が難しい劣化*1 受信者の財産権の侵害とも言える。 受信者(顧客)の同意 消費者保護観点からより深い内容周知の上での同意が必要では無いか オプトアウトが可能かどうか ISPとしてのサービスが土管であるべきか否か 例えば、可逆圧縮での再圧縮なら良かったのかどうか 携帯キャリアが提供しているのは「インターネット」サービスかどうか iモード
WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
ブラウザキャッシュの挙動を見てみる - 日向夏特殊応援部隊
改めて勉強したかったので、こんなテストしてみました。 Apacheの設定とテスト内容 <VirtualHost *:80> ServerAdmin zigorou@localhost DocumentRoot /home/zigorou/www/cache ServerName cachetest.art-code.org ExpiresDefault "access plus 5 minutes" Alias /test1 /home/zigorou/www/cache/test Alias /test2 /home/zigorou/www/cache/test Alias /test3 /home/zigorou/www/cache/test <Location /test1> FileETag None ExpiresActive Off </Location> <Location
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
