タグ

HTTPに関するotakumesiのブックマーク (15)

  • GitBook – Knowledge management for technical teams

    GitBook brings all your technical knowledge together in a single, centralized knowledge base. So you can access and add to it in the tools you use every day — using code, text or even your voice.

    GitBook – Knowledge management for technical teams
  • Googleの新プロトコルQUICを試す - ぼちぼち日記

    1.QUIC仕様の公開 以前、「Googleが仕掛ける新プロトコルQUICとは何か」のブログエントリーを書いたのが2月末の事でした。それから4か月経ち、今朝Googleが初めてQUICの公表(Chromium Blog: Experimenting with QUIC)を行いました。 IE11のSPDY/3対応が判明した直後でした。なんというタイミングでしょうか。 また、近いうち(来週?)には HTTP/2.0 の Implementation Draft が公開される予定です。8月上旬には、GoogleMicrosoft等が集まって初めての HTTP/2.0 の相互接続試験を行う予定です。ただ今HTTP関連のプロトコルが急激に進化する真っ最中です。目が離せません。 2. で、QUICとは何なのか? 先のChromium BlogのエントリーでQUICは、 「Quick UDP Inte

    Googleの新プロトコルQUICを試す - ぼちぼち日記
  • ngrok - secure introspectable tunnels to localhost

    🤯 Support for Kubernetes Gateway API is now available in developer preview. Learn more ->

    ngrok - secure introspectable tunnels to localhost
  • HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様

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

  • Web over HTTPS

    Web over HTTPS DevFest Tokyo 2016 #devfest16 2016/10/0

    Web over HTTPS
  • フロントエンドエンジニアのための動画ストリーミング技術基礎

    動画はデータ容量が大きい 画像と違い、動画コンテンツはデータ容量がとても大きいため、データをダウンロードして再生するまでに待ち時間が発生します。 動画のデータ容量が大きい理由はとても単純で、動画は画像データが集合したものだからです。静止画像を人間の目が滑らかに感じられる速さで切り替えて表示することで絵を動かすという表現を実現しています(よくパラパラマンガに例えられますが、そんな感じです)。この人間の目が滑らかに感じる速さというのが 1 秒間に 30 枚だったり 24 枚を切り替えることになります。29.97 (≒30) fps とか 24 fps とかの数字を耳にしたことがあるかと思いますが、24 fps の場合は 1 秒間(s)の間(p)に 24 フレーム(f)を切り替えることを意味します。 データを全て自分の端末にダウンロードしてから再生しようとすると、かなり長い待ち時間が発生してしま

    フロントエンドエンジニアのための動画ストリーミング技術基礎
  • サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita

    Webでのプッシュ技術 HTTPはクライアント(ブラウザ)からリクエストしてサーバからレスポンスが返る一問一答型のプロトコルなので、基的にはサーバ側からブラウザに新着情報をリアルタイムで通知(プッシュ)できるようにはできていません。 しかしそれでもプッシュをしたいという場合にどうするかという話が出てきます。やり方には以下のようなものがあります。 ポーリング クライアントからサーバに定期的に新着を問い合わせるようにします。 最も原始的かつ確実なやり方。欠点は、最大でポーリング間隔の分だけ通知が遅延しうることです。 ロングポーリング(“COMET”) ポーリングなのですが、問い合わせを受けたサーバは新着情報がなければレスポンスを返すのをしばらく保留します。 そのあいだに新着情報が発生すれば即座にレスポンスを返しますし、一定時間経過したら何もなかったとレスポンスを返しましょう。 飛び交う通信内

    サーバからクライアントに送信する技術 - WebSocketを中心に - Qiita
  • ActionCable の README を読んでチャットアプリを作ってみた - Qiita

    Rails 5 の目玉(?)機能である ActionCable を触ってみようと、README を読んで単純なチャットアプリを作ってみました。簡単な説明とサンプルコードを載せます。 概要 WebSocket と REST である Rails を統合させた、Rails にリアルタイム機能を追加するためのものです。クライアントサイド (JS) と サーバーサイド (Ruby) の両方のフレームワークを提供します。 WebSocket? WebSocket は RFC6455 で定義されている、Web でリアルタイム通信を行うための通信技術です。最初にハンドシェイクと呼ばれる HTTP 通信を行うのですが、それ以降はサーバーとクライントを接続しっぱなしにして、ステートフルに TCP 通信を行います。WebSocket の利点は主に 2 つです。 サーバープッシュが可能(リアルタイム) HTTP

    ActionCable の README を読んでチャットアプリを作ってみた - Qiita
  • Token Based Authentication in Rails - Code School Blog

    Token based authentication is when an API client uses a token identifier to make authenticated HTTP requests. A lot of popular services offer token based authentication for connecting with their web API, like HipChat, Campfire, Backpack, Last.fm and many others. It’s not yet a standard, but there is an official draft that specifies the scheme. Token based authentication offers many benefits over H

    Token Based Authentication in Rails - Code School Blog
  • NSURLSession のまとめ - Qiita

    iOS7 より導入されたバックグランドで通信できるクラス。いまさらですが、はまった点などをまとめました。 バックグランドとは? ここでいうバックグランドとは、単にMainThreadでないスレッドという意味ではありません。 iOS のアプリの状態の一種で、通常アプリを使用している状態はフォアグランド(Foreground)といます。この状態でホームボタンを押す等の操作を行った際は、アプリは画面の裏側へ移動してサスペンド(Suspended)状態になります。サスペンド状態ではコードを実行することはできませんが、この前段階にコードを実行できる状態があり、それがバックグランド(Background)です。 今までは、位置取得や音楽再生等限られた用途しか使用できませんでしたが、iOS7から通信処理にも利用できるようになりました。 参照:App States and Multitasking NSU

    NSURLSession のまとめ - Qiita
  • HTTPとサーバ技術の最新動向

    デブサミ2016登壇資料。サーバ技術の評価軸、HTTP/2、サーバプッシュ、HTTPS化の負荷、Brotli、サーバ内スクリプティングを俯瞰

    HTTPとサーバ技術の最新動向
  • HTTP ページ上でのパスワード要求はやめましょう

    [これは Mozilla のセキュリティエンジニア Tanvi Vyas 氏のブログ記事 No More Passwords over HTTP, Please! を同氏の許可を得て翻訳したものです] Firefox 46 Developer Edition は、HTTP ページ上でログイン情報の入力を求められた場合、開発者に警告を行います。 ユーザ名とパスワードの組み合わせは、ユーザの個人データへのアクセスを管理する手段です。Web サイトはこうした情報を注意深く扱い、パスワードは HTTPS のような安全な (認証、暗号化された) 接続を通じてのみ要求すべきです。しかし残念なことに、HTTP のような安全でない接続でユーザのパスワードが扱われている例が 非常に多く 見られます。このプライバシーとセキュリティの脆弱性を開発者の皆さんに知らせるため、最新の Firefox Develope

    HTTP ページ上でのパスワード要求はやめましょう
  • http api design

    以下なドキュメントを発見しておりまして。 HTTP API Design Guide なんとなくメモをとってみました。 Contents として以下が列挙されています。 適切なステイタスコードを戻しなさい 戻すことができる全てのリソースを戻しなさい リクエストボディに含まれるシリアライズされた JSON を受け付けなさい ID じゃなくて UUID 使った方が良いですよ 標準的なタイムスタンプを使いましょう UTC 時刻は ISO8601 フォーマットで使いましょう 一貫性のあるパスフォーマットを使いましょう 小文字とダッシュを使いましょう 外部キーのリレーションは入れ子に 利便性をはかるため non-id dereferencing をサポートしなさい エラーの場合のレスポンスボディについて ETag ヘッダを含めなさい Request-Id ヘッダを API レスポンスに含めなさい P

  • http-server

    http-server: a simple static HTTP server http-server is a simple, zero-configuration command-line static HTTP server. It is powerful enough for production usage, but it's simple and hackable enough to be used for testing, local development and learning. Installation: Running on-demand: Using npx you can run the script without installing it first: npx http-server [path] [options] Globally via npm n

    http-server
  • 2015年Webサーバアーキテクチャ序論 - ゆううきブログ

    2023年03月31日追記:この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We

    2015年Webサーバアーキテクチャ序論 - ゆううきブログ
  • 1