タグ

http|httpsに関するfubar_fooのブックマーク (17)

  • Is using a CDN possible when you're running a HTTPS website?

  • REST入門

    第2版(2008年1月19日):翻訳者による注釈を追加しました。 ヘテロジニアスなアプリケーション間の通信を実装するための「適切な」手法について議論が行われているということを、あなたは知っているかもしれないし、知らないかもしれません。そういった状況下で、現在の主流は明らかにSOAP、WSDL、WS-*仕様という世界をベースとしたWebサービスにフォーカスしています。しかし、少数派の人たちの中で、より良い方法があると主張する人がいます。それが、REST(REpresentational State Transferの略)です。稿では、筋から外れることなく、RESTとRESTfulなHTTPアプリケーション統合への実用的な説明を試みようと思います。これらの考え方の説明については、より詳細に踏み込んで説明をするつもりです。私の経験上、誰かが始めてこのアプローチを経験することで一番議論が活発に

    REST入門
  • ステートレスとは何か

    RestWiki をたまに見直すと新たな発見があって面白い。 たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。 RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。 ステートフルサーバとステートレスサーバはどう違うのか。 まずは、ステートフルの例: 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員:

  • yohei-y:weblog: REST 入門

    語の REST のリソース集を以前作ったのだが、 日語では一般人向けの解説がない。 sheepman 氏の REST のページはすばらしいんだけど、多少わかっている人向けだ。 市山氏のプレゼン資料は RoyF の論文を詳しく解説していてよいのだけれど、いかんせんアカデミックすぎる。 技術的な要素も抑えつつ、入門者にもわかりやすい解説はないものかと探していたのだが、みつからない。 英語の文書を訳すことも考えたんだけど、あまりよいものが見つからない。 で、結局自分で書くことにした。 最初はひとつのポストで済ませるつもりだったんだけど、書き始めたら長くなってしまったので、複数のポストに分けることにした。 えらそうなことを書いたが、内容は「ないよりマシ」といったレベルだろう。 前書きが長くなったけど(ここから始まりです。ですます調なのは入門記事だから)、 この記事(から始まる一連のポスト)は

  • PHPとJavaScriptでHTTPストリーミングする話(Transfer-Encoding: chunked編) - id:anatooのブログ

    HTTPレスポンスをajaxでストリーミング的に受け取りたいとき、要するにHTTPストリーミングをしたい時には、Transfer-Encoding: chunkedなレスポンスを生成してやるとよい。こうするとAjaxではHTTPレスポンス全体を受け取るのを待たずに、レスポンスの中身にアクセスすることが出来るようになる。従って、一つのHTTPコネクションでサーバ側から任意のデータを好きなタイミングでプッシュすることが出来る。 コード 一秒ごとに生成されるJSONをストリーム的に受け取るデモのコードが以下。 <?php // push.php function output_chunk($chunk) { echo sprintf("%x\r\n", strlen($chunk)); echo $chunk . "\r\n"; } header("Content-type: applicati

    PHPとJavaScriptでHTTPストリーミングする話(Transfer-Encoding: chunked編) - id:anatooのブログ
  • グーグルが高速プロトコル「SPDY」をChromeブラウザで有効化。Gmailなどで利用を開始していた

    グーグルが高速プロトコル「SPDY」をChromeブラウザで有効化。Gmailなどで利用を開始していた グーグルがより速いWebを実現するために、HTTPを高速化した新プロトコル「SPDY」を開発中であることは、昨年夏に公開した記事「グーグルがWebを高速化するために何をしているか」で紹介しました。 SPDYの話題はその後ほとんど見かけなくなりましたが、グーグルはそのSPDYをChromeに実装し、同社のサービスで利用していることがニュースサイトConceivably Techの記事「Google Chrome Gets SPDY – And An Onscreen Keyboard」で指摘されています。 なぜグーグルはひっそりとSPDYを有効化したのだろう? SPDYとは従来のWebのプロトコルであるHTTPを改良し、毎回同じ情報がやりとりされるヘッダの情報を圧縮したり、リクエストの回数

    グーグルが高速プロトコル「SPDY」をChromeブラウザで有効化。Gmailなどで利用を開始していた
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • ブラウザキャッシュとレスポンスヘッダ - murankの日記

    ブラウザキャッシュとレスポンスヘッダの関係を調べてみた。 調べたブラウザ Firefox 3.5 IE 6 Opera 9.64 Google Chrome 2.0.172.33 レスポンスヘッダ Expires Last-Modified Cache-Control Pragma 結論 以下のレスポンスヘッダを返す。 Expires、Last-Modified、Cache-Control、Pragma 以外のヘッダについては任意。 キャッシュさせたい場合 Cache-Control: private, max-age=有効期間の秒数 条件付GETをさせたい場合 Expires: 過去の時刻 Last-Modified: 過去の時刻 キャッシュさせたくない場合 Cache-Control: no-cache 調査方法 それぞれのブラウザで以下のレスポンスヘッダを返すページを読み込んだときに

    ブラウザキャッシュとレスポンスヘッダ - murankの日記
  • ブラウザキャッシュによる HTTP 高速化チューニング

    かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の3つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。

  • 開発メモ: 50行のC++コードでWebサーバを実装する

    「Kyoto Tycoonの設計 その四」改め、50行でWebサーバを書く方法を解説する。前回実装した「多重I/Oマルチスレッド汎用TCPサーバ」の上にHTTPの処理を行う層をつけて、「多重I/Oマルチスレッド汎用HTTPサーバ」を司るクラスを実装してみたので、それを使ってちょちょいとやる。 URLクラス HTTPと言えばURLが使えないと意味がない。URLは単なる文字列として扱ってもよいのだが、様々なシーンで分解や加工が必要になり、その処理はなにげに複雑で面倒なので、予めクラスとして導出しておいた方がよいだろう。 class URL { public: // 文字列のURLを解析して内部構造を作る void set_expression(const std::string& expr); // スキーム要素を設定する void set_scheme(const std::string&

  • Varnish (software) - Wikipedia

    Varnish is a reverse caching proxy[2] used as HTTP accelerator for content-heavy dynamic web sites as well as APIs. In contrast to other web accelerators, such as Squid, which began life as a client-side cache, or Apache and nginx, which are primarily origin servers, Varnish was designed as an HTTP accelerator. Varnish is focused exclusively on HTTP, unlike other proxy servers that often support F

  • 高木浩光@自宅の日記 - 共用SSLサーバの危険性が理解されていない

    ■ 共用SSLサーバの危険性が理解されていない さくらインターネットの公式FAQに次の記述があるのに気づいた。 [000735]共有SSLの利用を考えていますが、注意すべき事項はありますか?, さくらインターネット よくある質問(FAQ), 2010年2月10日更新(初出日不明) Cookieは、パスなどを指定することができるため、初期ドメイン以外では共有SSLを利用している場合にCookieのパスを正しく指定しないと、同じサーバの他ユーザに盗まれる可能性があります。 (略) 上記については、「同サーバを利用しているユーザだけがCookieをのぞき見ることができる」というごく限定的な影響を示していています。また、Cookieの取扱いについて、問い合わせフォームやショッピングカート等、ビジネス向けのウェブコンテンツを設置されていなければ特に大きな問題とはなりませんが、個人情報を取り扱われる管

  • InfoQ: HTTPSコネクションの最初の数ミリ秒

    ほとんどの人がHTTPSとSSL (Secure Sockets Layer) を結びつけて考えます。SSLは1990年代半ばにNetscape社が開発した仕組みですが、今ではこの事実はあまり正確でないかもしれません。Netscape社が市場のシェアを失うにしたがって、SSLのメンテナンスはインターネット技術タスクフォース(IETF)へ移管されました。Netscape社から移管されて以降の初めてバージョンはTransport Layer Security (TLS)1.0と名付けられ、1999年1月にリリースされました。TLSが使われだして10年も経っているので、純粋な"SSL"のトラフィックを見ることはほとんどありません。 Client Hello TLSはすべてのトラフィックを異なるタイプの"レコード"で包みます。ブラウザが出す先頭のバイト値は16進数表記で0x16 = 22。 これは

    InfoQ: HTTPSコネクションの最初の数ミリ秒
  • Corkscrewを使ってHTTP経由でSSHのトンネリング接続を行う - builder by ZDNet Japan

    記事では、「Corkscrew」というクロスプラットフォームプログラムを利用し、HTTP経由でSSHのトンネリング接続を行う方法を紹介する。 あなたには、出社してから必要なファイルを自宅に置き忘れてきたことに気付いたという経験はないだろうか?あるいは、出先でこういった忘れ物に気付いたことはないだろうか?企業やISPのなかには、こういった状況への対応を困難にする厳しいファイアウォール設定がなされているところもある。そして実際に、こういった厳しい設定が絶対に必要だというケースが存在している一方で、それほどではないというケースも存在している。とは言うものの、HTTPプロキシの使用が強制され、SSHが使えない環境であっても、HTTPプロキシを経由してSSHに接続することが可能なのである。 先に述べておくが、記事は外部へのSSHアクセスがポリシーで明示的に禁じられている環境において、ファイアウォ

  • Mozilla — 利益ではなく、ユーザーのためのインターネット

    このサイトが機能するために必要な Cookie に加えて、あなたの閲覧のニーズをより理解し、エクスペリエンスを向上させるために、追加の Cookie を設定する許可をお願いします。プライバシーは侵害しませんのでご安心ください。

    Mozilla — 利益ではなく、ユーザーのためのインターネット
  • ロボット排除プロトコル(REP)とは?――メタタグやrobots.txtの基礎 | Web担当者Forum

    HTTPヘッダーとは、ウェブサーバーがウェブブラウザなどのクライアントに対してデータを送る前に送信する情報のことで、通常はブラウザには表示されない。 多くの場合、HTTPレスポンスコード、コンテンツの種類(HTMLなのかPDFなのかなど)、コンテンツのサイズ、最終更新日付などの情報が含まれている。 HTTPヘッダーの内容は基的にHTMLページの記述などでは変更できず、サーバーの設定や出力プログラムの設定によって変更できる。ただし、HTMLページ内の「meta http-equiv」のタグによって、HTTPヘッダーで指定する情報を記述でき、ほとんどのウェブブラウザがmeta http-equivの情報を解釈する。 そして2005年に登場したサイトマッププロトコルでは、(XML)サイトマップを通じて大量のコンテンツを検索エンジンに登録する手続きが定義されている。 また2005年には「rel=

    ロボット排除プロトコル(REP)とは?――メタタグやrobots.txtの基礎 | Web担当者Forum
  • 葉っぱ日記 - レジストリの HKCR¥MIME¥Database¥charset 以下に定義されています。

    UTF-7を利用したXSSは、charset が指定されていない場合に発生すると考えられていますが、少なくとも Internet Explorer においては、これは大きな間違いです。正しくは、Internet Explorer が認識できる charset が指定されていない場合であり、charsetが付加されていても、IEが認識できない文字エンコーディング名である場合にはXSSが発生します。 例えば、次のような HTML は(HTTPレスポンスヘッダで charset が明示されていない場合)IEが文字エンコーディング名を正しく認識できないため、その内容からUTF-7と解釈されるためにスクリプトが動作します。"utf8"という表記はUTF-8の慣用的な表現ではありますが、ハイフンが抜けており正しい表記ではありません。 <html> <head> <meta http-equiv="Co

    葉っぱ日記 - レジストリの HKCR¥MIME¥Database¥charset 以下に定義されています。
  • 1