Webに関わる人のための『HTTPの教科書』を発売 - うさぎ文学日記
ひさびさの単著となる『HTTPの教科書』が2013年5月24日に発売になります。 内容はタイトルの通り、Webに関わる全ての人に捧げるHTTPを学ぶための教科書です。基礎を学びたい初心者の方から、机の上に置いてリファレンス的に使いたい方までを対象としています。 HTTPの教科書発売元: 翔泳社価格: ￥ 2,730発売日: 2013/05/25posted with Socialtunes at 2013/05/21 HTTP関連の書籍は『今夜わかるHTTP (Network)』というタイトルの本を2004年に出しています。その頃からHTTP/1.1が主流であるというのは、今でも変わりませんがそれを取り巻く環境というのは変わりつつあります。 HTTPを学ぶ上での要点がわかりやすく、そして読みやすくなっております。前作のリニューアルっぽく感じるかと思いますが、9割以上は書き直しや追記しており
X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記
2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。 年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に
Webサイト高速化に必要なHTTPの仕組みを理解する （1/4）：CodeZine
はじめに こんにちは、クラスメソッド株式会社でWebを担当している野中です。これから身につけるWebサイト高速化テクニック第2回目です。 第1回の「Webサイト高速化対策の現状」は読んでいただけましたか？「Webサイト高速化対策の現状」では高速化対策がなぜ必要なのかを紹介しているので、この回を読む前にぜひ読んでおいてください。 今回は、Webサイトの高速化に大きく関係するHTTPについて復習したいと思います。高速化対策と言ってもWebサイトが遅延する原因はさまざまです。 読み込むファイル数が多いことやサーバー側の処理に時間がかかっている、またはエンドユーザーが利用しているネットワークが原因かもしれません。 ところが原因を探っていくと、Webサイトが遅くなってしまう要因の多くにHTTPが関係しています。 実際の高速化手法も大事ですが、事前知識としてHTTPについて知っておきましょう。 対象読
GmailがハマったSPDYの落とし穴 - ぼちぼち日記
1. SPDYブーム到来 おかげさまで、ここ数日 SPDY が私の周りで非常にブームになってきています。 前回案内したSPDY＆WS勉強会は既に200名以上の申し込みがあり、今ではSPDYネタでブログを書くと非常に注目されるうれしい状況です。時代はまさに、 SPDYはハイプサイクルを順調に駆け上がっている 状況だと思います。 図１：2012年のハイプサイクル： 図はガートナー社のプレスリリース http://www.gartner.co.jp/press/html/pr20120906-01.html から引用 SPDYが、まだ黎明期に入ったばかりなのか、それとも既にピーク期に入ったのか、それは歴史が証明してくれるでしょう。 ということで勉強会までSPDY熱が冷めないよう、私もいろんなSPDYネタを出していきたいと思います。 2. GmailがハマったSPDYの落とし穴とは 先日、 Goo
次世代規格 HTTP2.0 のファーストドラフト公開 - Block Rockin’ Codes
intro 少し経って、去る11月28日に、HTTP プロトコルの次期規格となる HTTP2.0 のドラフト、 draft-ietf-httpbis-http2-00 が、IETF の httpbis ワーキンググループで公開されました。 このドラフトは Google から提案された仕様である SPDY が採用されています。 HTTP1.1 からのアップデート HTTP1.1 の RFC が提出されたのは 1999 年で、 13 年経った今年 2012年8月 に、 HTTP の仕様を議論する httpbis というワーキンググループが、 HTTP1.1 のアップデート版になる仕様、 HTTP2.0 の策定を開始しました。 これは、 HTTP1.1 の仕様策定がある程度落ち着いてきたこと、次期仕様を考える良い時期であること、 そしてなによりも、 Web の使われ方が大きく変わり、 求められて
IPA ISEC セキュア・プログラミング講座：Webアプリケーション編 第5章 暴露対策：プロキシキャッシュ対策
第5章 暴露対策 プロキシキャッシュ対策 プロキシキャッシュへのコンテンツ残留 ブラウザとWebサーバの間には、いくつかのキャッシュメカニズムが働いていることが多い。 プロキシサーバのキャッシュ──企業等LANを運用している多くの組織体ではLANからインターネットアクセスを行う際プロキシサーバを経由して行うことが多い キャッシュサーバ─インターネットプロバイダの中には、会員のWebアクセスを円滑にする目的でキャッシュサーバを運用しているところがある これらのキャッシュメカニズムは、ブラウザからのリクエストによって得られたコンテンツをキャッシュに保持しておき、同じURLのリクエストが生じたとき、本来のWebサーバにコンテンツを取りに行かず、キャッシュの内容をブラウザに渡すものである。 このようにキャッシュは、円滑なインターネットの利用に寄与してくれる。 しかし、コンテンツによっては、ただひと
HTTPリクエストの削減とWebサイト高速化まわり - Archiva
Make a note of it: Web tech, montaineering, and so on. Note: この記事は、3年以上前に書かれています。Webの進化は速い！情報の正確性は自己責任で判断してください。 メモ書き。社内説得用。「HTTPリクエストを減らすと高速化できるよ！」てのはよく聞くけど、それが「どうしてか」ってのを(読込待機時間まわりで)具体的な数字を出してることが意外と少なかったので。詳しくは参考リンクにGo! Webサイトを分析するWebアプリ PageSpeed Insights WebPagetest 参考資料など Webパフォーマンス最適化のためのコーディング手法, MOL @importを使うべきでない理由, Screw-Axis まずHTTPリクエストがコストが高い理由ですが、まあ同時読込できないからですよね。読込に1秒掛かる画像A,B,Cがあると
HTTP 2.0はグーグルのSPDYがベースになる？ 議論開始の提案がIETFで
「新しいバージョンのHTTPについての作業を開始する機が熟したのではないか」。HTTP 1.1仕様の改版を議論しているIETFのHTTPbisワーキンググループのメーリングリストに1月24日、このようなメッセージが議長のMark Nottingham氏から投稿されました。 現在議論されているのは、RFC2616で規定されたHTTP 1.1仕様のバグや問題の修正などで、基本的にこれまでのHTTPと互換性があることを前提にした仕様です。これが2月にラストコールとなることから、そろそろ次のHTTPについての議論をスタートさせよう、と呼びかけが始まったのです。 HTTP 2.0の議論を含む新しい憲章案も メッセージは、「We're getting close to Working Group Last Call.」（ワーキンググループの作業もラストコールに近づいてきた）と始まります。もうすぐ4年あ
ネットワークプログラミングの基礎知識
ネットワークプログラミングの基礎知識 ここでは IP アドレスやポート番号、クライアントとサーバの役割などを説明し、 perl・C言語・Java などでソケット (Socket) を使った HTTP クライアントや POP3 クライアント、簡単なサーバを作成してみます。 要はネットワークプログラミングをやってみよう、ということです。 このページのサンプルプログラムは、RFC などの規格に準拠した「正しい」プログラムではありません。 また、全体的にエラー処理が不十分です (今後改善する予定です)。 あくまでも概要を理解するためのサンプルととらえてください。 もし本気でしっかりとしたクライアントやサーバを書きたいなら、このページを読んだ上で、 さらに RFC を熟読し、そして wget・Apache・ftp コマンドなどのソースを参考にしてください。 このページに間違いを見付けたら、掲示板 で
PSGI - Perl WSGI
bulknews.typepad.com Tatsuhiko Miyagawa's blog to discuss mostly tech and nerdy stuff. Info: if you come from Google and want to know what PSGI and Plack are: take a look at our PSGI/Plack project web page that has links to PSGI spec and FAQ, and then Plack git repo for the actual code. HTTP::Engine is the best thing that happened in the Perl web application development land lately. It's a port of
RFC2616: ハイパーテキスト転送プロトコル -- HTTP/1.1
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
クライアントを作るにあたっての注意点
RFC とは ネットワークプログラムはクライアントとサーバが協調して動かなくてはいけません。 そのためクライアントとサーバの動作をあらかじめ決めておく必要があります。 HTTP や POP3 など、今から作ろうとするクライアントについても きちんとプロトコルが規定されており、RFCとして公開されています。 普通のプログラムの場合、適当に書いても動けばいいや的な考え方でも 他に迷惑をかけなければ (異常にメモリを食うとかしない限り) 許されますが、 ネットワークプログラムの場合、クライアントが変なことをすると サーバや利用者に迷惑がかかります。 まぁ、HTTP や POP3 くらいならあまり迷惑がかかる人もいないのですが、 NNTP クライアントや SMTP クライアントの場合、news購読者や メールを受け取る人に直接被害が及びます (Microsoft の News リーダ、メーラーの評
ポート番号
ポート番号とは? 「ポート番号」という言葉を聞いたことのない人もいるかもしれませんが、 わかってしまえば簡単です。 ネットワークプログラミングというのを 簡単に言ってしまえば、どこか別の場所で動いているプログラムと データのやりとりをすることです。 インターネットの中から一台のコンピュータを指定するには、 IPアドレスを使えばいいのですが、前項で書いたように、 ひとつのコンピュータでは複数のサーバソフトウェアを動かすことができます。 そのため、IPアドレスで1台のコンピュータを特定したとしても、 そこで動いているどのサーバプログラムとデータをやりとりしたいのかを 特定できません。 そこで出てくるのがポート番号というものです。 IPアドレスによって世界中から一台のコンピュータを特定でき、 さらにポート番号を指定することで、その中の一つのサーバプログラムを 特定できます。 サーバは特定のポート
HTTP/1.1: Status Code Definitions
part of Hypertext Transfer Protocol -- HTTP/1.1 RFC 2616 Fielding, et al. 10 Status Code Definitions Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required in the response. 10.1 Informational 1xx This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminat
URL 末尾のスラッシュは必要？
+1 ボタン 2 AMP 11 API 3 App Indexing 8 CAPTCHA 1 Chrome 2 First Click Free 1 Google アシスタント 1 Google ニュース 1 Google プレイス 2 Javascript 1 Lighthouse 4 Merchant Center 8 NoHacked 4 PageSpeed Insights 1 reCAPTCHA v3 1 Search Console 101 speed 1 イベント 25 ウェブマスターガイドライン 57 ウェブマスタークイズ 2 ウェブマスターツール 83 ウェブマスターフォーラム 10 オートコンプリート 1 お知らせ 69 クロールとインデックス 75 サイトクリニック 4 サイトマップ 15 しごと検索 1 スマートフォン 11 セーフブラウジング 5 セキュリティ 1
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。 これは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[Studying HTTP] HTTP Header Fields
【HTTP2.0最新動向】第1回：HTTP/2.0の策定、ついに始まる 
studyinghttp.net - このウェブサイトは販売用です！ - 解説 仕様書 利用 技術 である 手法 日本語訳 プログラミング リソースおよび情報
Studying HTTP
