タグ

関連タグで絞り込む (11)

タグの絞り込みを解除

httpに関するgriefworkerのブックマーク (16)

  • RESTFulなAPIとCSRFとその対策 - シアトル生活はじめました

    Cross-Site Request Forgery（クロスサイトリクエストフォジェリー）って何？ 頭文字をとって「CSRF」ですが、出来るだけ平たく説明すると 「悪いヤツが作ったサイトから読み込んだHTMLやらスクリプトが、勝手に別のサイトにHTTP POSTのリクエストを送信して、知らない間にそのサイトにある自分のデータなどを変更される」 といった感じになるかな。 データの中には重要なデータもあるでしょう。Amazonで欲しい物リストがあったとして、それが全部勝手に「購入」されたら困りますよね。銀行の口座から別の口座にお金が入金されても困ります。（もちろん、Amazonや銀行のサイトなどではCSRF対策がしっかりと施されているでしょうから、大丈夫！・・っであることを祈る） Cross-site とは二つのウェブサイトを跨いでること。サイトのひとつは当然「悪いヤツのサイト」でもうひとつは

    RESTFulなAPIとCSRFとその対策 - シアトル生活はじめました

  • QUICをゆっくり解説(16)：ヘッダ圧縮 | IIJ Engineers Blog


    たとえば、メソッドの値がGETという擬似フィールドを表現するには、2というインデックスを指示すればよいわけです。フィールドの表現として存在するのは以下の3つです。1つのインデックスでフィールド名とフィールド値の両方を指示する インデックスでフィールド名を指示し、フィールド値は文字列で指示する フィールド名とフィールド値の両方とも文字列で指示する2)と3)の文字列の部分では、Huffman符号を使って圧縮するか否かを選べます。また、2)と3)には、それぞれ以下3つの版があります。 動的表に登録する 動的表に登録しない 動的表に登録しない。加えてセキュリティのため、中継装置で伸長後、再圧縮される場合も、常に文字列による指示を使用する制約を付ける 動的表には大きさの制限があり、エントリでいっぱいになると、古いエントリが削除されていきます。動的表にはデフォルトの大きさがありますが、復号側がS
    QUICをゆっくり解説(16)：ヘッダ圧縮 | IIJ Engineers Blog

  • QUICをゆっくり解説(15)：HTTP/3 | IIJ Engineers Blog


    Haskellコミュニティでは、ネットワーク関連を担当。4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。QUICは汎用的なトランスポート層プロトコルですので、様々なアプリケーションプロトコルのやりとりに使えます。みなさんがよく知っているHTTP/1.1を乗せることも可能です。実際、開発者の間では、HTTP/1.1の前身の前身であるHTTP/0.9がテスト用に使われていました。 しかし、QUIC上のHTTPの本命は、第一回目の記事で説明したようにHTTP/3です。QUICは、﹁HTTP/2のストリームによる多重化の機能﹂を取り込んでいます。QUICに取り込まれなかったHTTP/2の残りの部分をQUIC用に再定義したのがHTTP/3です。 今回は、HTTPの標準化状況とHTTP/3について説明します。 HTTPの標準化状況 現在よく使われて
    QUICをゆっくり解説(15)：HTTP/3 | IIJ Engineers Blog

  • QUICをゆっくり解説(7)：アプリケーションデータとストリーム | IIJ Engineers Blog


    Haskellコミュニティでは、ネットワーク関連を担当。4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 これまでの記事で、QUICのコネクションを確立する手順について説明しました。今回は、いよいよコネクションを使って、アプリケーションデータをやりとりします。 ストリーム ストリームとは、QUICコネクションの中で、順番を守って配送されるバイト列のことです。アプリケーションのデータが、ストリームとして運ばれます。たとえば、あるHTTPの要求とそれに対する応答は、QUICでは1つのストリームとして扱われます。QUICコネクションの中では、複数のストリームが利用できます。ストリーム間ではタイミングを気にする必要はありません。HTTP/1.1のように応答が返ってきた後に次の要求を出すのではなく、複数の要求をあたかも同時に送り、それぞれの応答を
    QUICをゆっくり解説(7)：アプリケーションデータとストリーム | IIJ Engineers Blog

  • Idempotency-Key Headerを使ったリトライと、オンラインイベントの"Kaigi感" - inSmartBank


    去る2021年10月23日に開催されたKaigi on Rails 2021にて、弊社の@ohbaryeが "Safe Retry with Idempotency-Key Header" というタイトルで発表してきました。 発表スライドはSpeakerDeckにて公開済みです。 後日アーカイブ動画も公開されるとのことですのでそちらも是非ご覧頂きたいのですが、おとなしく30分の動画を視聴できるほど現代人は暇じゃないですよね。なので本記事の前半では忙しい人のために発表内容を1/10ぐらいの密度で解説してみます。 (2021-10-31追記) 動画が公開されました 🎉 www.youtube.com (2021-10-31追記おわり) ただ、それだけでは配信動画をすでに視聴いただいた方への新規情報がゼロになってしまうので、後半では発表に関していただいたtweet・質問・感想へのコメントへのリ
    Idempotency-Key Headerを使ったリトライと、オンラインイベントの"Kaigi感" - inSmartBank

  • QUICをゆっくり解説(2)：ネゴせよ | IIJ Engineers Blog


    Haskellコミュニティでは、ネットワーク関連を担当。4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。QUICへの誘導 前回のブログで、ブラウザが HTTP/3 (HTTP over QUIC) に対応したサーバにアクセスしたときに、最初は HTTP/2 を使い、2回目の通信からHTTP/3を使うようになると説明しました。今回は、この過程でクライアントとサーバが何を折衝しているか、以下の順で解説します。 TLSのバージョン HTTPのバージョン HTTP/2からHTTP/3への誘導QUICのバージョン TLSのバージョン あるURLで指定されたサーバにクライアントがアクセスすることを考えます。URLは、httpsで始まっていたとしましょう。つまり、TLSの中でHTTPが使われます。現在推奨されているTLSのバージョンは、1.2と1.
    QUICをゆっくり解説(2)：ネゴせよ | IIJ Engineers Blog

  • 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奥氏が解説（前編）


    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/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）

  • RESTful API設計におけるHTTPステータスコードの指針 - Qiita


    RESTful APIを設計した際のステータスコードの指針です。 メソッド別 GET 成功した場合 200 OK‥最も一般的 304 Not Modified‥条件付きGETでキャッシュを使わせたい場合 POST 成功した場合 201 Created 作成したリソースのURIを示すLocationヘッダを付けておく 議論 200 OKだとまずいのか？ 200 OKを応答する実装も多くあり、まずいというわけでもない 200 OKはPOST結果がキャッシュ可能、201 CreatedはPOST結果がキャッシュ不可能として分けてもいいが、そこまでする必要があるか？︵POSTのキャッシュは一般的ではない︶ 204 No Contentだとまずいのか？ クライアントがPOST結果を事前に全て知っているわけではないのでNo Contentは不親切では？ 失敗した場合 409 Conflict‥作成しよ
    RESTful API設計におけるHTTPステータスコードの指針 - Qiita

  • HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD


    HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breakerbreaker, this is White Chocolate Thunder. We'vegot a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月7訳‥HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。﹁ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
    HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD

  • キャッシュについて整理 - Qiita


    キャッシュとは 使用頻度の高いデータを高速な記憶装置に蓄えておくことにより、いちいち低速な装置から読み出す無駄を省いて高速化すること。また、その際に使われる高速な記憶装置や、複製されたデータそのもののこと。 - IT用語辞典 Webサイトの表示においては、一度アクセスしたページのデータを特定の場所に保存することで、次回アクセス時の表示を速くし、サーバへの無駄なリクエストを減らせるというメリットがあります。また一口にキャッシュといっても下記の2種類があるので、どちらを指しているのか︵あるいは両方か︶意識しておきましょう。 ブラウザのキャッシュ‥そのパソコンのユーザーが見たページのデータがローカルに溜まっていく。 キャッシュサーバのキャッシュ‥不特定多数のユーザーが見たページのデータがネットワーク上に溜まっていく。 キャッシュの制御方法 ✏️ HTTPレスポンスヘッダ で制御 ➡️ Cache
    キャッシュについて整理 - Qiita
    griefworker
    griefworker 2017/10/31
    「オリジンサーバでの確認無しにキャッシュを利用してはならない」なのに、no-cache というのは名前が悪い。
    リンク

  • 独自ヘッダをチェックするだけのステートレスなCSRF対策は有効なのか？ — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something

    「WebAPIのステートレスなCSRF対策」という2011-12-04の記事がありました。 ここで説明されているCSRF対策は、 GET、HEAD、OPTIONSメソッドのHTTPリクエストはCSRF保護の対象外 HTTPリクエストにX-Requested-Byヘッダがなければエラーにする という非常にシンプルなものです。 そして、この対策の原理として以下の説明がありました。 form, iframe, imageなどからのリクエストではHTTPリクエストに独自のヘッダを付与することができません。独自のヘッダをつけるにはXMLHttpRequestを使うしかないわけです。そしてXMLHttpRequestを使う場合にはSame Origin Policyが適用されるため攻撃者のドメインからHTTPリクエストがくることはない、ということのようです。 ここで、 XMLHttpRequestを使

  • HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様


    今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための︵レスポンスボディに載せられる︶標準的な形式が、RFC7807 Problem Details for HTTP APIsで定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
    griefworker
    griefworker 2017/01/18
    RFCがあるのか。
    リンク

  • 奥一穂さんインタビュー - Tokyo RubyKaigi 11


    13:25 Invited Speaker 最速ウェブサーバの作り方 近年、ウェブの体感速度は、ネットワークのバンド幅ではなくレイテンシによって律速される傾向が強まってきています。また、それに伴い、TCP Fast Open、HTTP/2、TLS 1.3といった、レイテンシの影響を削減／隠蔽する技術の標準化が進んでいます。本セッションでは、HTTP/2サーバ﹁H2O﹂の主開発者が、レイテンシの影響削減を主目的とするサーバのプログラミング技法や、HTTP/2の更なる高速化を実現する手法として標準化提案中の﹁Cache Digest﹂等を紹介し、それらをrubyから制御する手法を検討します。 必要となる知識 TCP/IPとUnixのソケットプログラミングに関する基礎的な知識があると、分かりやすいかと思います。 奥一穂 株式会社ディー・エヌ・エーMIT TR100、日本OSS貢献者賞受賞、未踏
    奥一穂さんインタビュー - Tokyo RubyKaigi 11

  • Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes


    Intro 先日 #http2study で mozilla の Richard Barnes が Let's Encrypt について話してくれました。 資料: Let's Encrypt Overview この資料の翻訳 はしたのですが、いらなくなってしまったので供養もかねてこのプロジェクトのモチベーションと、 Web でおこっている HTTPS 推進のたどる道について、資料を補足しつつ紹介します。 結論から言うと Let's Encrypt はもちろん ACME プロトコル についても是非知っておくと良いと思います。 HTTPS の問題 すでにこのブログでも紹介しているように、 Web における HTTPS の重要性は増し、それの普及を後押しする活動が各所で進められています。 HTTPS 化する Web をどう考えるか よく言われる盗聴防止を始め、暗号化を行うことで防げる問題は多くあ
    Let's Encrypt を支える ACME プロトコル - Block Rockin’ Codes
    griefworker
    griefworker 2015/11/09
    早くベータ終わって正式公開して欲しい。
    リンク

  • Kazuho's Weblog: ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話

    ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話 ウェブページの表示までにかかる時間をいかに短くするかってのは、儲かるウェブサイトを構築する上で避けて通れない、とても重要な要素です。 少し古いデータとしては、たとえば、ウェブページの表示が500ミリ秒遅くなると広告売上が1.2%低下するというBingの例なんかも知られているわけです。 「ウェブページの表示までにかかる時間」と言った場合、実際には以下のようないくつかのメトリックがあります。 イベント 意味

  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.