タイムライン取得時400 Bad Requestエラーが起きている

[hayamiz]

タイムライン取得時400 Bad Requestエラーが起きている

[cvmat]

configuration.xmlの取得失敗後、その次に実行されたAPIでエラーが起きてるようですね。
エラーの内容から推測するとHTTP response headerが正しく取得(もしくは抽出)できていない
のかもしれません。
(setq twittering-debug-mode t)
としておくと通信に使用したbufferを消さずに残すようになります。
twmode-http-bufferという名前のbufferをチェックしてみてください。
nの部分の数字が大きいほど新しいbufferです。問題のエラーが、どういう
HTTP responseに対して起こっているかがわかれば対処できそうです。

ただ、気になる点としては
(setq twittering-use-ssl nil)
としているのに https://api.twitter.com/ にアクセスしているのが不思議です。

[luozengbin]

ご回答ありがとうございました。

ただ、気になる点としては
(setq twittering-use-ssl nil)
としているのに https://api.twitter.com/ にアクセスしているのが不思議です。

先ほど(setq twittering-use-ssl nil)設定の反映が忘れたので通信がhttpsなっていたです。
改めて設定を反映して、debugモードで実行してみました。やはり、400エラーが出ています。

http通信ログ

[03/Oct/2011 13:31:25] "GET http://api.twitter.com/1/account/verify_credentials.xml HTTP/1.1" 200 -
[03/Oct/2011 13:31:26] "GET http://api.twitter.com/1/help/configuration.xml HTTP/1.1" 400 -
[03/Oct/2011 13:31:27] "GET http://api.twitter.com/1/statuses/home_timeline.xml?include_entities=true&count=20 HTTP/1.1" 200 -

２個目のリクエストのレスポンスコードが400です。
レスポンス内容は↓

<?xml version="1.0" encoding="UTF-8"?>
<hash>
  <error>Rate limit exceeded. Clients may not make more than 150 requests per hour.</error>
  <request>/1/help/configuration.xml</request>
</hash>

１個目と３個目以降のレスポンス内容は正しいようですが、ライムラインの表示ができないままでした。

[luozengbin]

すみませんが、何か対処方法はないでしょうか？

[cvmat]

400であることが認識できているので、問題なのはconfiguration.xmlの取得の方ではないと思います。
実際、 configuration.xml は取得できなくてもデフォルトの値を使うだけで大きな問題にはならないはずです。
問題はその次に発行されるhome timeline 取得でのサーバ応答でしょうね。home timelineの方のbufferは残って
ないでしょうか？
また、
(setq debug-on-error t)
としておくと、split-stringのエラーのbacktraceが取得できると思います。どの関数でエラーになって
いるのかがわかるので手がかりになります。

ただ、 configuration.xml 取得のエラー内容は少し変です。OAuthの場合はrate limitは150ではなく350になる
はずです。さらにrate limitでエラーが出ているなら次のhome timeline 取得でも同じエラーになるはずですが
HTTP response status 200を返すのもおかしいです。
もしかして何か別のTwitter互換サービスをお使いだったりしますか？

[luozengbin]

400であることが認識できているので、問題なのはconfiguration.xmlの取得の方ではないと思います。
実際、 configuration.xml は取得できなくてもデフォルトの値を使うだけで大きな問題にはならないはずです。
問題はその次に発行されるhome timeline 取得でのサーバ応答でしょうね。home timelineの方のbufferは残って
ないでしょうか？

実はconfiguration.xmlの取得は成功したり、失敗したりなのでした。
configuration.xml取得の成功、失敗に関わらずhome_timeline.xml間隔的取得で次のようなxmlが返してくれる。

<?xml version="1.0" encoding="UTF-8"?>
<statuses type="array">
  <status>
    ....省略
  </status>
  <status>
    ....省略
  </status>
</statuses>

だが、_home_バッファーに何も表示されていない。
home_timeline.xml取得するたびにsplit-stringのエラーが起きる。
backtraceの内容が長すぎで、段取りして貼ります。

Debugger entered--Lisp error: (wrong-type-argument stringp nil)         
  string-match(";" nil 0)                                               
  split-string(nil ";")                                                 
  (cdr (split-string content-type ";"))                                 
  (let* ((content-type ...) (parameters ...) (regexp "^[[:space:]]*chars
  (cond ((or ...) (debug-printf "connection-info=%s" connection-info) (l
  (case-string status-code (("200") (debug-printf "connection-info=%s" c
  (let ((status-line ...) (status-code ...)) (case-string status-code (.
  twittering-http-get-default-sentinel(#process *twmode-generic* 1 ex
  apply(twittering-http-get-default-sentinel #process *twmode-generic*
  省略

内容から見るとtwittering-http-get-default-sentinel関数でhrader-infoリストから
Content-Type要素を参照しようとしているがnilで落ちている。

header-infoリストを確認したところ、Content-Type要素がなくて、小文字のcontent-type要素となって
いる。試しに小文字のcontent-type要素を参照するようにソースを直してみた、_home_バッファーにタ
イムラインの内容がちゃんと表示できた。;-)

次ぎはheader-infoの一部です。

header-info 
      '(
        ("status-line" . "HTTP/1.0 200 OK") 
        ("http-version" . "HTTP/1.0") 
        ("status-code" . "200") 
        ("reason-phrase" . "OK") 
        ("Server" . "BaseHTTP/0.3 Python/2.6.3") 
        ("Date" . "Tue, 04 Oct 2011 02:26:12 GMT") 
        ("via" . "HTTP/1.1 GWA") 
        ("vary" . "Accept-Encoding") 
        ;; 省略
        ("content-type" . "application/xml; charset=utf-8") 
        ;; 省略
      )

もしかして何か別のTwitter互換サービスをお使いだったりしますか？

いいえ、別のTwitter互換サービスは利用していないです。
ただしプロキシサーバーは自分のGAE appspotに乗っているサービスを利用しているけど、
それに関係するかもしれない。

一応問題解決できたのでIssueをクローズさせていただきます。
いろいろとアドバイスして頂いて、ありがとうございました。

[cvmat]

According to RFC2616, field names of HTTP header should be case-insensitve.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2.
So, this issue should be treated as a bug of twittering-mode. I will commit the fix of the bug soon.
Can I mention your name as the reporter of this bug in the ChangeLog of the fix?
If you allow it, which name do you prefer? luozengbin or other?

[luozengbin]

thanks for you information about RFC2616. I would like to use luozengbin as the reporter name.

[cvmat]

I have commited the fix.
Would you please try it?
If it works well, close this issue, please.

[luozengbin]

it works well. thanks.