rjとtとjqコマンドでHTTPレスポンスを試験する - ゆーすけべー日記
Web 開発者は HTTP レスポンスをよく見る。 以前 CDN を導入する際に、キャッシュがヒットしているかどうか、どこのエッジがキャッシュを返しているかを確認するためにヘッダをよく見ていた。また、ヘッダだけではなく、TTFB といったレスポンスタイムも気にしている。とにかく HTTP レスポンスをよく見る。 HTTP レスポンスを確認する３つの方法 Chrome さえあれば DevTools を見て一目瞭然である。 とはいえ、コマンドラインで確認したい時がしばしばある。 GUI を操作するよりも手軽である。 その場合はcurlコマンドを叩けばよい。 これでプロトコル、ステータス、ヘッダが分かる。 また、レスポンスタイムを測りたければ、その名もttfb.shというcurlをラップしたコマンドラインツールがある。 https://github.com/jaygooby/ttfb.sh この
HTTPキャッシュ入門の入門 – cat /dev/random > /dev/null &
ローカル・経路上のキャッシュを併用しよう キャッシュは再利用されるほどいいものです。 サイトの規模にもよるのですが、ローカルと経路上のキャッシュはそれぞれ性質が異なるため、ブラウザキャッシュだけ適切に設定しておけば経路上では不要というわけではありません。 ローカルキャッシュはキャッシュを持つクライアント自身がサイトを再訪する場合は有効ですが、キャッシュを持っていない新規クライアントには無効です。 経路上のキャッシュは新規クライアントに対してもキャッシュを返すことができるため、例えばサイトへの流入が突然増えるといった事態でも対処がしやすいです。 そのためコンテンツ次第ではありますが、ブラウザキャッシュのように特定のクライアントでしか使えないprivate cacheにするよりも、 効率を考えてローカル・経路上のどちらでもキャッシュができ、多数のクライアントで共有できるshared cache
Kazuho Oku on Twitter: "HTTP を使うサーバクライアントアプリ作ってる人が、HTTP 的にどうするのが正しいのかな、と迷った時、見るべきドキュメントは BCP56bis かな、という話をした。HTTP の仕様ではなく、どのように使うべきかを説明した文書… https://t.co/7ke9ePZtTn"
HTTP を使うサーバクライアントアプリ作ってる人が、HTTP 的にどうするのが正しいのかな、と迷った時、見るべきドキュメントは BCP56bis かな、という話をした。HTTP の仕様ではなく、どのように使うべきかを説明した文書… https://t.co/7ke9ePZtTn
責任ある開発者のためのHTTPヘッダー | Yakst
安全で、誰にも手頃でアクセスしやすく、ユーザーを尊重したWebを作るためのHTTPヘッダーのプラクティス [UI/UX]原文 HTTP headers for the responsible developer - Twilio (English) 原文著者 Stefan Judis 原文公開日 2019-04-23 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket msh5 原著者への翻訳報告 1821日前 メールで報告済み 編集 This article was originally published on twilio.com, and translated with the permission of Twilio and the author. 当記事の原文はtwilio.comにて公開されたものであり、Twilio社および原著者の許可を得て翻訳しています
Kotlin コルーチンでネットワーク I/O 処理実験 - Qiita
Kotlin のコルーチンを勉強中。 Kotlin のコルーチンは、Python のコルーチンのようにシングルスレッドで実行されるわけではなく、スレッドプールを用いた M:N スレッドモデルが採用されている。 Java を使うことは近年ほとんどなかったので余り知識がないところではあるが、Java のネットワーク I/O 周りの処理は基本的にブロッキングするものだと捉えている。著名な HTTP ライブラリもそのはず。 そのようなブロックするネットワーク処理を同時に多数実行しようとした場合、コルーチンを使って非同期に扱ったとしても、バックグラウンドのスレッドがブロックしてしまうので、結局は多くのスレッドを生成しなくてはいけないのではないか？ スレッドは高価なのでリソースが枯渇してしまうのではないか？ そのような疑問が生じてきた。 Go の Goroutine も M:N スレッドモデルだが、ブ
QUICとHTTP/3時代のインターネット解説書はどうあるべきだろう - golden-luckyの日記
OSI参照モデルとTCP/IPモデル なぜいまでもOSI参照モデルによる説明が多いか QUICは、TCP/IPモデルのトランスポートとはいえるが、OSI参照モデルのレイヤ4とはいいにくい HTTP/QUICモデル QUICをどう解説するか OSI参照モデルとTCP/IPモデル かつてぼくたちは、7つのレイヤに分かれたOSI参照モデルという姿でコンピュータネットワークを学び、その7層のモデルにそって各種のプロトコルを理解しようとしていました。 だから、「SONET/SDH上のATM回線でIPパケットをやり取りする」という構想をきけば、「つまり、SONET/SDHがレイヤ1で、ATMがレイヤ2で、IPがレイヤ3なのだな」という枠組みを頭に描いていました。 と同時に、OSIのレイヤとはいったい……、というアンビバレントな想いにさいなまれることもよくありました。 「SONET/SDHがレイヤ1って
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか？ 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途
ログアウト機能の目的と実現方法
このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。 議論の前提 このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持 前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
