RFC 7233 — HTTP/1.1: Range Requests （日本語訳）
【 この~RFCは、 今や，`現在の~HTTP中核~仕様＠~HTTPcommon#core-specifications$（ ~RFC 9110 ）により廃用にされた。 】 ◎要約 ~HTTP（ Hypertext Transfer Protocol ）は、分散型の協調的な~hypertext情報~system用の、`~stateless$な~app~levelの~protocolである。 この文書は、`範囲~要請$, および その種の要請に対する応答を構築する／結合するための規則を定義する。 ◎ The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This
Transfer-Encoding: chunked について - 理系学生日記
Tomcat をコンテナとした Servlet のコード上で Content-Length ヘッダを設定していたのですが、なぜか HTTP レスポンスのヘッダには Content-Length が出力されないという事象が確認されました。 これは一体なぜなのだろうと調べていると、当該レスポンスのヘッダに Transfer-Encoding: Chunked が出力されていることに気付きました。 Chunked は HTTP/1.1 で定義されている方式です。RFC 2068 には以下のような記述があり、Chunked と Content-Length を共存させてはいけない (MUST NOT) ことが分かります。) Messages MUST NOT include both a Content-Length header field and the "chunked" transfer
HTTP Headers という 5万人が使っている Chrome 拡張のマルウェア疑惑。セッション盗まれて BTC も盗まれそうになった話。 - clock-up-blog
疑惑どころか 99.99% くらい黒な話。 （後記：セッション盗まれたと思ってたけど、よくよく考え直してみると生パスワードごと盗まれてる可能性もあるしやばい） 追記：続報 11月3日 今回指摘した HTTP Headers 以外にも、「Tab Manager」「Give Me CRX」「Live HTTP Headers」等で同様（？）の問題が報告されています。第三者が元の作者からソフトウェア権利を買い取って悪用する、というケースが割とある模様（？）。皆さま情報ありがとうございます。 11月4日 Zaif については、「不正な Chrome 拡張」と「スクリプトから保護されていなかったクッキー」のコンボによりセッションが盗まれていた可能性あり。 Zaif のセッション情報が盗まれた原因のひとつについて。JavaScript からクッキー値を取得させない方法。 - clock-up-blog
Sprayの簡単な紹介 - アドファイブ日記（ミラー版）
Scala Advent Calendar 2013の10日目担当記事です。みんなガチな人ばかりで怖いです。あまり期待しないでください。 ググっても日本の記事があまりないSprayの紹介をしてみます。 あと表題と関係ないですが最近書いたPlayFrameworkにSlickやSecureSocialを入れたメモを掲載しておきます。 Play2.2へのSlickのインストール Play2の認証ライブラリSecuaSocialを使う Sprayについて Akkaをベースに非同期モデルで実装された超ハイパフォーマンスなHTTP処理フレームワークという感じのもの。型システムがあって非同期でマルチスレッド（アクター）対応しててプラグインがある程度揃ってるHTTPサーバやWebフレームワークってScalaにしばらなくても少なそうです。ハイフリークエンシ―なWebアプリケーションやREST-APIを作る
HTTP/2のRFCを読んだ感想
はじめに 私は自ら「串職人」と名乗るほどウェブの(つまりHTTPの）Proxyサーバが好きで、もう10年以上もプロキシサーバを作り続けています。このブログの主題であるクラウド型WAF、Scutumもそのひとつです。そもそもプロトコルとしてのHTTPが好きです。ウェブの裏側に、とてもシンプルな、テキストベースのHTTPプロトコルが活躍しているということが私の串職人としての出発点です。 HTTP/2が出た 先日、ついにHTTP/2が出ました。 数年前から、「SPDY」などのキーワードに代表される次世代のHTTPが模索されていることは何となく知っていましたが、どうもGoogleのような非常に大きいトラフィックを処理している組織が主導しているもので、一般の開発者やウェブの利用者にとってそれほど魅力的なものではなさそうだな、という印象を抱いていました。 サーバ側を作っているのもGoogle、ブラウザ
HTTP 2.0最新動向インタビュー - IETF httpbis wg チェア Mark Nottingham氏:Geekなぺーじ
TOP > ブログ > HTTP 2.0最新動向インタビュー - IETF httpbis wg チェア Mark Nottingham氏 昨年後半、IETFのhttpbisワーキンググループでHTTP 2.0標準化に向けた動きが開始されました。 そのhttpbisワーキンググループのチェアであるMark Nottingham氏(Akamai)に対するインタビューの機会を頂けました。 Mark Nottingham氏は、HTTP 2.0標準化の舵取りをしている方です。 非常に興味深い最新状況を伺えたので、可能な限り生に近い情報をお届けします(日本語に翻訳する前の英語版はこちら)。 お楽しみ頂ければ幸いです。 Q: HTTP 2.0標準化開始の経緯を教えて下さい HTTP 1.1とHTTP 1.0には、よく知られた制限があります。 特に顕著なのが、ひとつのコネクションでリクエストを出してレス
人間とウェブの未来 - 軽量な静的コンテンツ配信におけるHTTP/2とSPDYのWebサーバの性能を見てみよう
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 既存のHTTPやWebサーバの技術を見ているものとして、新しい技術も調査しておかないといけないなということで、今日はHTTP/2とSPDYでおしゃべり可能なWebサーバの性能を見てみたいと思います。 HTTP/2の実装としては、tatsuhiro-tさんのC言語実装ライブラリであるnghttp2に注目しており、今日はそのライブラリを使って実装されているWebサーバnghttpdを動かし、SPDY/3.1で動作しているnginxとの性能比較をしました。HTTP/2やSPDY/3.1はもちろんクライアント側も既存のベンチマークツールではおしゃべりできないので、nghttp2で実装されているh2loadを使用しました。weighttpと使い方が似て
1行のbashスクリプトで実現するWebサーバー | ソフトアンテナ
普段複雑で高機能なWebサーバーに馴染んでいると忘れがちなことですが、HTTPの基本的なしくみはとてもシンプル。それを証明しているのが「Web server in one line of bash」です。なんと以下の1行のbashスクリプトでWebサーバーの機能を実現しています。 while true; do { echo -e 'HTTP/1.1 200 OK\r\n'; cat index.html; } | nc -l 8080; done 実行してみよう 適当なHTMLファイルをindex.htmlという名前で保存し、ターミナルで上記コマンドを実行。ブラウザから「http://localhost:8080」にアクセスしてみましょう(ポート番号が8080になっていることに注意)。 index.htmlのサンプル <html> <head><title>Hello</title></h
Lucb1e.com :: Cookieless Cookies
Cookieless cookies There is another obscure way of tracking users without using cookies or even Javascript. It has already been used by numerous websites but few people know of it. This page explains how it works and how to protect yourself. This tracking method works without needing to use: Cookies Javascript LocalStorage/SessionStorage/GlobalStorage Flash, Java or other plugins Your IP address o
Googleの新プロトコルQUICを試す - ぼちぼち日記
1.QUIC仕様の公開 以前、「Googleが仕掛ける新プロトコルQUICとは何か」のブログエントリーを書いたのが2月末の事でした。それから4か月経ち、今朝Googleが初めてQUICの公表(Chromium Blog: Experimenting with QUIC)を行いました。 IE11のSPDY/3対応が判明した直後でした。なんというタイミングでしょうか。 また、近いうち（来週？）には HTTP/2.0 の Implementation Draft が公開される予定です。8月上旬には、GoogleやMicrosoft等が集まって初めての HTTP/2.0 の相互接続試験を行う予定です。ただ今HTTP関連のプロトコルが急激に進化する真っ最中です。目が離せません。 2. で、QUICとは何なのか？ 先のChromium BlogのエントリーでQUICは、 「Quick UDP Inte
小人閑居して: 女の子からの相談への返事でわかるHTTPステータスコード
2013年4月26日金曜日 女の子からの相談への返事でわかるHTTPステータスコード 100番台 100 Continue 「どうぞ、続けて？」 200番台 200 OK 「そうだね」 202 Accepted 「受理しました」 「え？」 「受理しました。返事はまだ決まってないけど」 204 No Content 「うーん、話は全部きいたけど僕にできるアドバイスはないよ」 300番台 301 Moved Permanently 「これまでは僕が相談に乗ってたけど締め切った。なので今度からはコイツに相談してね」 302 Moved Temporarily 「ごめん用事があるから今回はコイツに相談して」 303 See Other 「あのさ、相談するんだったら俺よりふさわしい相手がいるんじゃないの？」 305 Use Proxy 「直接言うんじゃなくて仲
WebSocketの中身を覗いてみる - m-kawato@hatena_diary
この記事は、HTML5 Advent Calendar 2012の15日目のエントリーです。 WebSocketは、Webサーバ・ブラウザ間で双方向に通信するための仕様であり、APIとプロトコルがそれぞれ以下の規格で定義されています。 API: W3C WebSocket API プロトコル: IETF RFC 6455 - The WebSocket Protocol (日本語訳) Node.js + Socket.IO のようなライブラリを使うと割と簡単にWebSocketが使えますが、中で何が起こっているかもう少し追ってみたいという動機により、tcpdump+WireSharkによるパケットキャプチャを通してWebSocket通信の中身を調べてみました。 作業環境 サーバ側、クライアント側ともホストはWindows 7 (64ビット版) で、サーバはその上の仮想マシンとして動かしてい
次世代規格 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 の使われ方が大きく変わり、 求められて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://jp.techcrunch.com/2015/10/06/20151004why-the-internet-needs-ipfs-before-its-too-late/
iOS上にHTTPサーバを立ち上げる方法 - Qiita
ParseがRubyからGoへ移行，信頼性が大きく向上
Google、SPDYのサポートを終了し、次期ChromeでHTTP/2に移行
https://jp.techcrunch.com/2014/05/28/20140527bttn/
HTTP/2はどうなるか
サービス終了のお知らせ