【info】有料サポート(ベータ)限定 承り中 /【JSサポート(仮称)】
【費用】 とりあえず、言い値で承ります。ただし、できる範囲での限定受付です。込み具合等によりお受けできない場合がありますのであらかじめご了承ください。サポートにご納得いただけなければ料金は不要です。 逆に感動したら多くても構いません(^^;;;。
【できること】 たとえば、かも日記で無料配布されているコードのカスタマイズや、あるいは、JavaScript/Ajax全般+Webサーバーとの連携などのアドバイス&サンプル作成等 。A:jQchartなどでWeb用グラフ設置(エクセル→CSVやデータベースからWebグラフ生成)などのアドバイスやカスタマイズサンプル作成。B:ツリーメニューなどのカスタマイズサンプル。C:Google Mapsのカスタマイズ。etc...
【できないこと】 腕立て伏せ200回
【ライセンス】 私が今まで「かも日記」等で提供してきたコードの大半は、商用利用、改造、自由、連絡不要で、今後もそれらは変わりません。そして、この有料サポートによりカスタマイズコードなどが提供される場合でも、同様に、それらを商用利用しても改造しても自由です。ただし、制限のきついライブラリなどを使う場合は、各ライブラリのライセンスに準拠せざるを得ない場合があります。
【info】いつもいろいろなテストなどをページ内のあちこちでやっているので、重かったり、壊れていたりするf^^;ことも多いですが、何卒、ご了承ください ( _ _ b
べきとう性って漢字書けます?
http://ja.wikipedia.org/wiki/%E5%86%AA%E7%AD%89
ってすぐ下に答えを書いてますがf^^;;
この漢字、書く以前に、読めませんでした。というか、何度も見てはいたんですが読み飛ばしていたので読み方を知りませんでしたf^^;。ベキ乗のベキなんですけれど、学校でこの漢字を覚えた記憶が無いです。冪が常用漢字に含まれないせいかなぁ。<単なる勉強不足。
HTTPでいうと、GET (HEAD, PUT, DELETE も)は冪等{idempotent} なメソッドなので、キャッシュしても良い。
とか、
POSTは冪等{idempotent} なメソッドではないので、キャッシュしない。
という言い方になるわけです。べきとうせい。。。語源は何なんだろう?ベキとは?
p.s.ちなみにJavaScriptで冪乗(Xをn回掛け合わせた積)は、Math.pow(X,n)ですね。Math.pow(2,2)なら4でMath.pow(2,2)なら8という具合です。
数学の行列なんかでベキ乗しても自分自身になる場合に使うのを聞いたことがあります
多分この概念じゃないかと・・・
エキサイト辞書で調べたら、雲などが一面におおうさまを「べきべき」と言うのだそうです。言語の意味を類推する作業って、連想ゲームのようです(^^;
エキサイト辞書
大辞林 第二版 (三省堂)
べきべき 【冪冪】<
(ト/タル)[文]形動タリ
雲などが一面におおうさま。
「―たる雲を貫ぬいて/趣味の遺伝(漱石)」
http://www.excite.co.jp/dictionary/japanese/?search=%E5%86%AA&match=beginswith&itemid=18256600
そういえば、ベキッと折れた感じの記号「^」を使って、2^2とか書くので、「ベキ」と納得していたような記憶も。
以前 X01HT(IE)ののRequest Headerを採取しましたが、 今回、NetFront3.4 も試してみました。
コメントを書ける場所についての覚書で、XHRのリクエストヘッダでRangeを使って、ファイルの先頭に書いたコメントを読むという検討をしましたが、このテクニックは、実際に、どの程度有効なのか?を押さえておきます。
http://jsgt.org/lib/ajax/051/test/test_setHeader_range_bench.htm
約2Mのファイルを、Rangeをセットして200バイトのみAjax読み込みする場合と、0バイト目以降を全部読み込む場合、そして、普通にファイル全部を読み込む場合の三通りで処理時間を計測しました。
ちなみに、LAN接続+Win XP IE6+Pentium4 2.6G+2GRAM では、下記の結果でしたので充分に効果はあるといえると思います。
追記:2006.12.7
上記は静的.txtファイルでの計測でしたが、php、perlからのベンチも試してみました。phpでは、効果が逆転していることが要注意です。(p.s. PHPの設定は、チューンナップをしていません)
#しかし、.txtで15/1000秒に対して、.phpで421/1000秒という違いは大きいですね。。。やはり、まめに静的ファイル化すると幸せがくる?かなぁ。
#とりあえず今日の結論::リクエストヘッダにRangeを使用した、データの部分取得では、.txtや.htmlなどの静的ファイルを対象とすると、取得データ量に見合った、パフォーマンスアップを期待できる。PHPやPerlなどを介するケースでは、逆に、遅くなるケースもあるので要注意。
右のBBSのスパムがひどいですね。
http://blog.drecom.jp/naito/archive/319#comments
みたいに、数字を入力しないと書き込めないようにすると少しはへるのでしょうかね。
JavaManさんおひさしぶりです。スパムはきりが無いので、多少対策した後、放ってあったのですが、このBBSでの放置は、やはり、気になりますか、、、f^^;。
The XMLHttpRequest Object
W3C Working Draft 19 June 2006
http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060619/
#20060405版でわかりにくかったsetRequestHeaderの許可範囲が明示されていますね。信じていいのかな^^?>Opera
setRequestHeader
http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060619/#dfn-setrequestheader
・Implementations MUST replace any existing value if the nominated request header field value is one of(ざっくり訳::実装(ブラウザなど)は、指定されたリクエストヘッダーのフィールド値が以下のひとつであるならどんな既存の値も置き換えなければならない):
Authorization, Content-Base, Content-Location, Content-MD5, Content-Range, Content-Type, Content-Version, Delta-Base, Depth, Destinaion, ETag, Expect, From, If-Modified-Since, If-Range, If-Unmodified-Since, Max-Forwards, MIME-Version, Overwrite, Proxy-Authorization, SOAPAction or Timeout.
Otherwise, if the nominated request header field already has a value, the new value MUST be combined with the existing value (section 4.2, [RFC2616]).
(ざっくり訳::あるいは、指定されたリクエストヘッダーのフィールド値がすでにあるなら、新しい値を既存の値に結合しなければなりません(section 4.2,[RFC2616])
IETF RFC 2068
8.2.4 サーバが早まって接続を閉じた場合のクライアントの振る舞い
http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616#Sec8.2.4
W3C HTML 4.01/4.0
17.13.3 フォームデータの処理
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/interact/forms.html#h-17.13.3
http://www.asahi-net.or.jp/~bd9y-ktu/html4rec_f/interact/forms.html#h-17.13.3
IETF RFC 1738
Uniform Resource Locators (URL)
http://www.mars.dti.ne.jp/~torao/rfc/rfc1738-ja.txt
ECMA-262 3rd
15.1.3 URI 処理関数のプロパティ (URI Handling Function Properties)
http://www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/15-1_Global_Object.html#section-15.1.3
IETF RFC 2388
フォームから返される値: multipart/form-data
http://www.studyinghttp.net/cgi-bin/rfc.cgi?2388
IETF RFC 2616
HTTP/1.1 3.4.1 Charset の誤り
http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616#Sec3.4.1
W3C HTML 4.01/4.0
5.2.2 文字符号化方法の指定
http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/charset.html#h-5.2.2
http://www.asahi-net.or.jp/~bd9y-ktu/html4rec_f/charset.html#h-5.2.2
XForms 1.0 11.6 Serialization as application/x-www-form-urlencoded
http://www.w3.org/TR/xforms/slice11.html#serialize-urlencode
リクエストヘッダ HTTP1.1
例:oj.setRequestHeader("Range","bytes=500-999")
【説明】エンティティの一部をリクエストします。 条件なしGETの場合は、成功したら ステータスは、200 (OK) の代わりに 206 (Partial Content)を返す。 条件付きの GET の場合は、条件が偽なら304。
【テスト内容】500〜999バイト目をリクエストします。リクエストするファイルtest.txtの中身は、次の通り。
【結果】このテスト用ファイルの500〜999バイト目である、6〜0にかけての文字列が返ります。
【メモ】データの位置を指定して必要な部分だけリクエストしたり、ファイルを分割して受け取ったりできます。位置をバイト数で指定できますので、たとえば、固定長なフォーマットのデータを処理するという使い方も出来るかも。 【雑談】フラグメント
【サンプル】
>マップを状況に応じて読み込む
まさに適任かも。
Operaがだめです。
Content-Typeは設定できるようになったので大丈夫かと思ったんですが、これは駄目っぽいです。裏技ないかな、、、。
http://la.ma.la/blog/diary_200507290022.htm
POSTだと8.02でうごくらしいですがどうでしょうか
とおりすがりさんありがとうございます。
でも、POSTもchk済みです。結構、周到にガードしているようです。いくつか試してみましたが、\r\nだけではなくて、許可したもの以外は通さない雰囲気?です(^^;。
とりあえず、Rangeをベンチマークしました。
回線速度によってかなり結果は異なりますが、
相対的な関係は同じかなと思います。テストのアベレージはISDNで試していますが、ちなみに光だと10倍程度違いました。
http://jsgt.org/ajax/ref/head_test/header/Range/003/sample.htm
光の結果も書いておきました。。。結論は、Rangeより、、、光を使え、ということかも(笑;;;<技術の進歩恐るべし、、、(^^;<とはいえ、光の土俵でも、パフォーマンスに違いがあるという事実を見逃してはいけない、、、<ふりだしへ。
高橋 ( 2005年12月04日 00:01 )004 | 固定長の名簿データをRangeでリクエスト
http://jsgt.org/ajax/ref/head_test/header/Range/004/sample.htm
を追加。ふと、、、Operaで使えないマイナスはあるにしても、それ以上に、このアプローチのメリットとして、HTTPの仕様通りにやってるわけですから、クライアント側もサーバー側も案外取替えが利きやすいかも、ということがあるかもしれません。<何のために?
高橋 ( 2007年10月24日 22:01 )今月からgzipで送り出しているせいかも?と思いますが、サンプルのlengthが間違っている?
帰りの車の中でふと思ったのですが、忘れないうちにメモ(^^;。
最近のWebは、RSSにしてもAjaxにしても、取り扱うデータが「全部」ではなく「断片」というケースが増えている気がします。XMLHttpRequestからみて、リクエストするページはいわゆるWebページである必要はなく、XMLでもJSONでもtxtでもCSVでも、何でも良くて、つまり、「データ」なのです。
で、ふと、XMLやHTMLをデータとしてみると、タグって少し高級なデリミタですよね。
なら、固定長なWebページデータがあってもよいんでは?
HTTPは、タグは理解できませんが、固定長なデータなら指定できます。つまり、ファイルデータを全部読み込まなくても、必要な一部分だけの断片(フラグメント)をリクエストすればもっと軽くなるんでは?
というわけで、リクエストヘッダ「Range」のテスト。
http://jsgt.org/ajax/ref/head_test/header/Range/Range.htm
問題は、そのフラグメントがどのファイルのどこにあるのかを効率よく教えてくれる方法をセットにすることですね、、、。でもそれもAjaxで取ってくればよさそうな。、、、あとは、日本語の問題、、、うー、今はそれは考えないことにしましょう(^^;;
リクエストヘッダ HTTP1.0/1.1
例:oj.setRequestHeader("If-Modified-Since","Tue, 22 Nov 2005 14:00:00 GMT ")
【説明】ファイルの更新確認。If-Modified-Sinceは、Range ヘッダを持たない場合に、 GET メソッドを条件付きにします(Range があると意味が変ります)。もし指定時刻以降に更新されていなければ、サーバはエンティティを返す代わりに、ステータスコード304 (not modified) のレスポンスをメッセージボディ無しで返さなければならず、その際いかなるレスポンスボディも返してはいけません。更新されていれば、メソッドがGETならステータスコードは200で、ボディを返します。日付は、RFC 2616 の section 3.3.1, 19.3, 19.4.3 にある3タイプ。ちなみに、時刻は、サーバーとクライアントが同期しているとは限らないので、サーバー側のものを使うべきです。RFC2616の14.25の注には、「直前の Last-Modified ヘッダフィールドにて受けたそのままの時刻文字列を使う事」が提案されています。
【テスト内容】If-Modified-Sinceヘッダで、テスト用ファイル「test.txt」がTue, 22 Nov 2005 14:00:00 GMT 以降に更新されたかどうかを確認してみます。
メソッドはHEADを使い、確認だけを行ってみます。また、ブラウザや設定で異なるキャッシュの動作を回避し強制アクセスするためにgetTimeをURIクエリへ追加しました。
【結果】このテスト用ファイルは、Tue, 22 Nov 2005 13:47:07 GMTに更新されて以降更新されていませんので、ステータスコード304が返ります。仕様には、GET時に使用とありますがHEADでは動作しています(サーバーは下記レスポンスヘッダの通り)。POSTでは無視されました。日付は、RFC 2616 の section 3.3.1, 19.3, 19.4.3 にある書き方を使用するようですが、更新チェックなら、実際の、レスポンスヘッダからLast-Modified値を利用すればよいのかな?と。
【メモ】たとえば、更新されたページのリンクへ[New!]などを表示したり、掲示板などに見られるリロード機構を多少ネットワークに優しくするなどの仕組みを、サーバー側ではなく、クライアント側に置けるようになります。
追記: 問題は、OperaのsetRequestHeaderIf-Modified-Sinceが動作しないというか動作させる気がないこと。
追記 2006.5.20.: 例::たとえば、通常は静的ファイルだけHEADでチェックし、更新時のみCGIへ分岐するとかするとCGI起動も減らせて良いかも。from ajaxメーリングリスト
【サンプル】
【info】有料サポート(ベータ)限定 承り中 /【JSサポート(仮称)】
【費用】 とりあえず、言い値で承ります。ただし、できる範囲での限定受付です。込み具合等によりお受けできない場合がありますのであらかじめご了承ください。サポートにご納得いただけなければ料金は不要です。 逆に感動したら多くても構いません(^^;;;。
【できること】 たとえば、かも日記で無料配布されているコードのカスタマイズや、あるいは、JavaScript/Ajax全般+Webサーバーとの連携などのアドバイス&サンプル作成等 。A:jQchartなどでWeb用グラフ設置(エクセル→CSVやデータベースからWebグラフ生成)などのアドバイスやカスタマイズサンプル作成。B:ツリーメニューなどのカスタマイズサンプル。C:Google Mapsのカスタマイズ。etc...
【できないこと】 腕立て伏せ200回
【ライセンス】 私が今まで「かも日記」等で提供してきたコードの大半は、商用利用、改造、自由、連絡不要で、今後もそれらは変わりません。そして、この有料サポートによりカスタマイズコードなどが提供される場合でも、同様に、それらを商用利用しても改造しても自由です。ただし、制限のきついライブラリなどを使う場合は、各ライブラリのライセンスに準拠せざるを得ない場合があります。
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 |