RSS/Atomを取得しているボットのHTTPリクエストヘッダを観察中

これまで確認した事がなかったという事実に思い至ったので、少し観察中です。

対象は有名どころのアグリゲータ(Webのフィードリーダーとかブログサーチ(ping)とか、とりあえずRSS/Atomを目的にしているボット)です。

Perlっぽい所はTEをよく使っているようですね。A-Imを使っているところもありますが、これは少数派。持続接続かそうでないかはまちまちのようです。

恥ずかしながら、TEとA-Imは何の事かよくわかっていなかったので勉強になりました(まだ理解しきれていませんが、なんなのかは覚えました)。まだまだ理解しきれてはいないので、おいおい調べていくつもりです。

TEを使うのは、keep-aliveでchunkedでdeflate(gzip)なあたりでほげほげという事でしょうか。"Connection: close"と"Accept-Encoding: deflate, gzip"であれば、安全?帯域について考えたときに足を踏み入れる領域でしょうか。

A-ImをつけてリクエストするUAは、どうもIf-Modified-Sinceなどはつけないようです。"delta encoding"だから不要という事でしょうか。BloglinesがA-Imをつけているので少々気になるところです。

TE

内容コーディングは内容を圧縮する事が念頭に置かれていますが、転送コーディングは、内容をあるエンコード方式に従って転送するという事を意味します。
転送コーディング :: [Studying HTTP] Message Body
転送コーディング値は、ネットワークを通して "安全な転送" を保証するために、エンティティボディに適用されている、する事のできる、する必要のあるエンコーディング変換を示すために使われる。
転送コーディングは、元のエンティティではなくメッセージの特性である、という点で内容コーディングとは異なる。
3.6 転送コーディング :: ハイパーテキスト転送プロトコル -- HTTP/1.1

A-Im

A-IM リクエストヘッダフィールドは Accept に似ているが、レスポンス中に受け入れ可能な instance-manipulation (section 10.1) を制限する。
section 10.5.2 にて明示されるように、レスポンスは複数の instance-manipulation を適用した結果であるかもしれない。
10.5.3 A-IM :: HTTPにおける差分エンコーティング
ステータスコード 226 は、Delta encoding in HTTPで定義されています。
サーバは、現在のインスタンス (現時点でのエンティティ) に差分コーディングを行い、その差分を返しました。実際に、どのようなインスタンス操作が行われたかは A-IM ヘッダフィールドに記述されています。
226 IM Used :: [Studyng HTTP] HTTP Status Code

久しぶりにFeedpathを触りましたが、feedpath.comでfeedpath.jpの証明書が使われているというアラートが出ました。どうしたのでしょう?


A-Imについて追記。"A-Im: feed"の場合は、以下のように動作するようです。

Atom フィードのダウンロード速度を上昇させる Apache モジュール。仕組みはフィルタモジュールとして動作し、Content Type が application/atom+xml の場合、クライアントから送られてくる If-Modified-Since ヘッダを調べて、新しい記事のフィードのみを配信するという仕組み。
mod_speedyfeed : NDO::Weblog

なるほど、観察中のものはRSS2.0なので、いくらクロールしてもIf-Modified-Sinceをつけてこないという訳ですかね。

一方、"A-Im: channel"はよくわかりません。RSS用の独自モジュール?

プロフィール

このブログ記事について

このページは、koshigoeが2007年9月 2日 00:21に書いたブログ記事です。

ひとつ前のブログ記事は「amazonの請求先住所を間違えた(けど気にしない)」です。

次のブログ記事は「ボス退職」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。