その10 ストーリー仕立てで学ぶトラブルシューティングのコツ Twitterクライアントの評価において検出したtwitterの問題

以下動画のテキストです。

https://youtu.be/pEbGTWSMCps

Transcript

1. ストーリー仕立てで学ぶトラブルシューティングのコツ Twitterクライアントの評価において 検出したtwitterの問題 Jul 5th, 2020 Satoru Takeuchi Twitter: satoru_takeuchi 1
2. もくじ • 問題発生 • 問題の絞り込み • 仕様かバグかの判断 • その後 • まとめ 2
3. もくじ • 問題発生 • 問題の絞り込み • 仕様かバグかの判断 • その後 • まとめ 3
4. 問題発生 • 背景 ▪ Shell scriptで作られたtwitterクライアントを見つけて興味を持って使ってみた ▪ https://github.com/piroor/tweet.sh • 期待される結果 ◦ 自分のtwitterアカウントに関するJSON形式のデータが出力される • 実際の結果 ◦ 普通の人類には理解できない文字列が出力された ◦ 再現性あり: 何度やっても同じ結果 $ ./tweet.sh showme �VMo�6�+��umZ_����b��4E ���F2�tH*�wHY�? �=�P֛7����>��<M� XE�<以下省略> 4
5. もくじ • 問題発生 • 問題の絞り込み • 仕様かバグかの判断 • その後 • まとめ 5
6. 発生個所の特定 • スクリプトの中のどこでおかしくなったのかを確認 ◦ スクリプトの実行ログを表示する bashの”-x”オプションを使用 ◦ curlコマンドでtwitter APIにリクエストを発行する際に発生した問題だとわかった • 上記コマンドを単独で実行しても同じ問題が発生するかを確認した ◦ twitter.shはたぶん悪くない $ bash -x ./tweet.sh showme <省略> ++ curl --get --header 'Authorization: OAuth <省略>' --data '' --silent https://api.twitter.com/1.1/account/verify_credentials.json ^_<8B>^H^@^@^@^@^@^@^@<AC>VMo<E3>6^P<FD>+<82><AE>umZ_<96>^ D<F4><D0><ED>b<8F><BD>4E<省略> 6
7. 出力結果は何者か • おそらくランダムなデータはでなく、データ形式が間違っている • Fileコマンドでファイル形式を調べた • Gzip形式だとわかったので展開したデータを見てみた ◦ 展開後のデータは正しそう ◦ なんとなくhttpのコンテンツボディの圧縮が関係していそう $ ../tmp/bin/curl --get --header 'Authorization: OAuth <省略>' --data '' --silent https://api.twitter.com/1.1/account/verify_credentials.json | file - /dev/stdin: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT) $ curl --get --header 'Authorization: OAuth <省略>' --data '' --silent https://api.twitter.com/1.1/account/verify_credentials.json | gunzip {"id":<略>} 7
8. curlの別バージョンを試す • 確認したバージョン ◦ v7.50.1(最初に検出したバージョン ): 発生する ◦ V7.35.0: 発生しない ◦ 7.52.2-DEV(問題検出当時のupstream master): 発生する • これからいえること ◦ V7.35.0からv7.50.1のどこかで問題が発生するようになった ◦ (当時の)最新版でも問題は依然発生する 8
9. 再現/非再現環境でのhttpリクエストの違いを確認 9 バージョン Twitterへアクセスする際の httpのバージョン Accept-Encodingヘッダ (許容する エンコーディング形式 ) Content-Encodingヘッダ (レスポンスの エンコーディング形式 ) 7.35.0(再現しない) 1.1 未指定 未指定(生のJSON形式を 示す) 7.52.2-DEV(再現する) 2.0 未指定 gzip
10. もくじ • 問題発生 • 問題の絞り込み • 仕様かバグかの判断 • その後 • まとめ 10
11. 仕様かバグか • 確認すべきこと ◦ http2.0においてAccept-Encodingヘッダ無指定時にgzip圧縮したデータを返してよいか • 見るべき仕様 ◦ RFC7231 ▪ accept-encoding • https://tools.ietf.org/html/rfc7231#section-5.3.4 ▪ Content-encoding • https://tools.ietf.org/html/rfc7231#section-3.1.2.2 • 調査結果 ◦ 仕様違反ではない ▪ this allows the server to use any content-coding in a response ◦ Curlが正しく解釈できないのも別に悪くはない ▪ It does not imply that the user agent will be able to correctly process all encodings. 11
12. 別の問題の検出 • 圧縮を許さない設定をした場合の挙動を確認 ◦ それでも結果は圧縮されていた ◦ これはtwitterの問題 12 $ curl --get --silent --header "Accept-Encoding: identity;q=1.0,*;q=0" https://api.twitter.com/1.1/account/verify_credentials.json | file - /dev/stdin: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)
13. もくじ • 問題発生 • 問題の絞り込み • 仕様かバグかの判断 • その後 • まとめ 13
14. その後 • Tweet.sh開発者へ ◦ 回避策を適用するPRを送った ▪ https://github.com/piroor/tweet.sh/pull/3 ◦ すぐマージされた • Twitter社へ ◦ 既存障害調査の結果、すでに issueがあることがわかった ▪ https://twittercommunity.com/t/twitter-api-doesnt-look-header-accept-encoding-identity/56571 ◦ 自分も同じ問題に遭遇したこと、および追加情報を補足 ▪ 例) 最小の再現プログラムの提供 ◦ 一年後に修正&closeされた 14
15. もくじ • 問題発生 • 問題の絞り込み • 仕様かバグかの判断 • その後 • まとめ 15
16. まとめ • トラブルシューティングの型を学んだ ◦ 再現性の確認 ◦ 絞り込み ◦ 仕様の確認 ◦ 最小の再現プログラムの作成 ◦ しかるべきところに連絡 16