リバースプロキシとは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
簡単に書くよ リバースプロキシ（英：reverse proxy）とは 恥ずかしがり屋なWebサーバさん（ホームページのファイルが置いてあるコンピュータ）の代理交渉人。 もう少し具体的に書くと Webサーバさんの身代わりになってホームページのファイルを返してくれるサーバさん（サービスを提供するコンピュータ）のこと です。 順番に見ていきましょう。 まずは予備知識として「プロキシ」について簡単に説明します。 「そんなの説明されなくても知ってるよ！」な人は適当に読み飛ばしてください。 プロキシは「ホームページを見るときに使うソフト（Webブラウザ）の身代わりになってホームページにアクセスしてくれるコンピュータ」です。 身も蓋もない書き方をすると、Webブラウザさんのパシリです。 詳細は用語「プロキシ」の説明をご覧ください。 それを踏まえて、文字通り、プロキシさんの逆バージョンが「リバースプロキシ
Extended Log File Format
This version: http://www.w3.org/pub/WWW/TR/WD-logfile-960323.html Latest version: http://www.w3.org/pub/WWW/TR/WD-logfile.html Authors: Phillip M. Hallam-Baker <hallam@w3.org> Brian Behlendorf <brian@organic.com> Status of this document This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other docum
Diigo Evernoteより動作が軽くて使いやすいWebクリップ - 小規模組織のためのフリーIT（アプリ、Webサービス）活用伝道日記
WebクリップツールのGoogleノートブックがサービスを終了した。以前よりサービスの更新は中止しており、近々サービスを中止すると宣言されていたが、ついにその日が来てしまった。 代替えのサービスとしてはかのEvernoteがありこれも併用して使っていたが、Googleノートブックに比べて起動や保存の動作が重いためあまり使ってはいなかった。 やはり、Webクリップは起動が軽くて操作が軽快にできるものでないと使いにくい。 そこで、Evernoteでないもっと軽量軽快に動作するWebクリップを探してみたところ、Zoho Notebookというのを見つけた。これは日本語化していて軽快に動作する。EvernoteのようにBookmark Letもあって操作も楽である。 Googleノートブックのブックマークもインポートできる。 しかし、問題点が一つあった。iPhoneのアプリが無いのである。iPho
SLOW BIZ Web情報のクリップツールを、Tumblrに一元化することにした。
02≪ 2024｜ 1234567891011121314151617181920212223242526272829303103/ ≫04 Evernote内の情報が膨大な数になってきている一方で、ネット上にはまた新しい情報が次々に出てきている現状。 ↓ 何かを調べるときに、過去の情報を検索するよりも最新の情報を検索したほうがいいに決まっている。 ↓ 今一度、Evernoteに情報を送る意味を考え直すことにしました。 ↓ Evernote内の情報は、数ヵ月後、数年後にも使える情報に絞るべきでは。 ↓ 長期間保存しておいても価値がある情報とは？ ・自分のアウトプット ・自分の感動した体験（心に残ったフレーズ、読んだ本、観た映画など） ・時代に左右されない他者の経験録・言葉（ライフハックや仕事術など） ・いつかやってみようと思うツール（ガジェット、Webサービスなど）のマニュアル記事・Tip
yohei-y:weblog: REST 入門
日本語の REST のリソース集を以前作ったのだが、 日本語では一般人向けの解説がない。 sheepman 氏の REST のページはすばらしいんだけど、多少わかっている人向けだ。 市山氏のプレゼン資料は RoyF の論文を詳しく解説していてよいのだけれど、いかんせんアカデミックすぎる。 技術的な要素も抑えつつ、入門者にもわかりやすい解説はないものかと探していたのだが、みつからない。 英語の文書を訳すことも考えたんだけど、あまりよいものが見つからない。 で、結局自分で書くことにした。 最初はひとつのポストで済ませるつもりだったんだけど、書き始めたら長くなってしまったので、複数のポストに分けることにした。 えらそうなことを書いたが、内容は「ないよりマシ」といったレベルだろう。 前書きが長くなったけど(ここから始まりです。ですます調なのは入門記事だから)、 この記事(から始まる一連のポスト)は
HTTPメソッドのPOSTとPUTの使い分け - アインシュタインの電話番号
どこで見たか忘れたけど、POSTはURLが変わる場合に使用して、PUTはURLが変わらない場合に使用する、と書かれたページを読んだことがあって、POSTとPUTの使い分けはそうするものだと思ってた。が、これは間違い^1っぽい。Webアプリ制作におけるバイブルとも言えるWebを支える技術を読み返していたら、これらの使い分けの指針が載っていて、それは自分が覚えてた使い方と逆だった。 POSTとPUTを使い分ける指針 POSTとPUTを使い分けるのに明確な答えはないみたいだけど、Webを支える技術では以下のような設計上の指針を紹介されていた。 これには正解は存在しませんが、設計上の指針として次の事実があります。 POSTでリソースを作成する場合、クライアントはリソースのURIを指定できません。URIの決定権はサーバ側にあります。逆にPUTでリソースを作成する場合、リソースのURIはクライアントが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://kanari.info/b/2065
Part2 URLの仕組みを知る