base64でエンコードされたコンポーネントを持つユーザーエージェント？
（一番下の賞金質問） 私たちのサイトにアクセスするクライアントに問題があります。根本的な原因は、WAF（Web Application Firewall）がユーザーエージェント文字列を好きではないことです。 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0; C7QcSBPWTsrpX5YLvVZMqiujEZLWPtOYk3tDZ9WhW18=) Gecko/20100101 Firefox/34.0 この場合、base64でエンコードされた文字列は、ユーザーエージェントがlibwww-perlであると考えるWAFで誤検知を引き起こしています。base64文字列は、読み取り可能なテキストにデコードされません。 ユーザーエージェント内にbase64でエンコードされた文字列があるのは正常ですか、それとも異常ですか？ User-Agent内でのbase64文字列の使用は、RFCまたは主要なベンダーの慣行でカバーされていますか？ ここで何が起こっているのかを理解しようとしています。WAFシグネチャがオブジェクトと完全に一致していないとは思わないので、無効にするだけでなく、この種のユーザーエージェント文字列を見たことがないので、一般的な方法と/またはこれが正当なユースケースです。 このサイトは、人間がブラウザで使用するように設計されており、APIなどではなく、ユーザーが「FF / IE / Chrome」でサイトにアクセスしようとして失敗したと報告されています。ただし、同じクライアントIPからOperaユーザーエージェントを使用して接続が成功したことを示しています。 User-Agent: Opera/9.80 (X11; Linux i686) Presto/2.12.388 Version/12.16 ユーザーがIEを試したと報告するのは少し奇妙ですが、私が目にするすべてのユーザーエージェント文字列はLinuxのようです。（いつものように、エンドユーザーとの連絡は複数の当事者を介して行われるため、聞いたことを完全に信頼することはできません）。また、IPがビジネスクラスのWebプロキシの発信側である可能性もあります。これは、誰かが同じIPから問題を報告しているのに、一部のOperaが誰かのために機能しているのを説明する理由です。 更新 @PlanetScaleNetworksの例に触発されて、文字列をグーグルし、そこからUA Trackerを使用してbase64文字列（または、埋め込まれた文字列のサブセット-「=）」を検索しました）。それは約20のユーザーエージェントを返しました： 私はこの質問に賞金を追加します。私が探している回答スペースは、「どのようなソフトウェアがbase64文字列をUser-Agentに入れているのか、そしてその理由です。そして、この実践には正当性の印がありますか？」 」 マイナーポイント： ユーザーはブラウザプラグインを使用してユーザーエージェントを変更することで問題を回避しているため、これは学術的な問題ですが、興味深い学術的な問題だと思います:)