web-dev-qa-db-ja.com

mozilla / 5.0 +以降のブラウザがユーザーエージェントに送信しているものはampに変換されます。

数年前から稼働しているウェブサイトがあります。顧客の1人が断続的な問題を抱え始めました。 iis6.0のログを見ると、「mozilla/4.0 +」で始まるユーザーエージェントがある場合、サービスは正しく動作しますが、ユーザーエージェントが「mozilla/5.0 +」で始まる場合は失敗します。特定の顧客は、水曜日にのみこの問題を抱え始めました。

4.0を5.0に変更するブラウザー/アップグレードを知っている人はいますか？

実際に発生する問題は、urlパラメータリストの「」が「amp;」としてエンコードされていることです。誰も似たようなものを見ましたか？

5.0+ユーザーエージェントを使用して問題なくブラウザから送信する他のユーザーがいます。

タグについては申し訳ありませんが、新しいタグを作成する担当者がいません。

事前に感謝、パトリック

編集：Viper_sbこんにちは、

ほとんどの場合、カスタムスクリプトです（私は主にC++開発者なので、あまり理解していません）。私たちのサイトは、他の顧客が開発したサイトからのリクエストを処理します。これは、私の知る限りJavaスクリプトで行われました。

実際にさまざまなユーザーエージェントを取得しています（おそらく、顧客がサービスにアクセスしている顧客によって異なります）。

Mozilla/5.0+(Windows;+U;+Windows+NT+6.1;+fr;+rv:1.9.1.11)+Gecko/20100701+Firefox/3.5.11
Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US)+AppleWebKit/533.4+(KHTML,+like+Gecko)+Chrome/5.0.375.126+Safari/533.4 302 0 0
Mozilla/5.0+(Macintosh;+U;+PPC+Mac+OS+X;+fr)+AppleWebKit/523.12+(KHTML,+like+Gecko)+Version/3.0.4+Safari/523.12
Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.9.2.8)+Gecko/20100722+Firefox/3.6.8
Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+fr;+rv:1.9.2.8)+Gecko/20100722+Firefox/3.6.8+(.NET+CLR+3.5.30729)
browsersuser-agentiis6url-encoding
1
Patrick

Firefox 3.xおよび他の多くのユーザーがサポートしています。

問題が発生しているエージェント文字列全体を投稿できますか？リクエストを生成し、特定のエージェントのふりをしているカスタムスクリプトのように思えます。しかし、ident文字列を誤って作成しています。または、エージェント文字列に対するチェックが正しくありません。

編集：投稿した文字列はURLエンコードされており、その中の+はスペースである必要があります。問題がJavaScript側にあるのか、サイトにアクセスしているユーザーにあるのかはわかりません。

私はここに出て、あなたのjavascriptがエージェント文字列をデコードしていると思います、これは起こるべきではありません（あなたがそれからURLを作るか、あなたのウェブサイトにそれを投稿するつもりでない限り）。

2
Viper_Sb

UA文字列の+は、IISが記録する方法が原因であると推測しています。

明確にするために、サイトのリンクにクエリ文字列があり、一部のUAは&ではなく&を使用してそれらのURLを要求していると言っていますか？

その場合、最も可能性の高い原因は、UA文字列をスプーフィングしている非常に愚かなボットです。適切に記述されたHTMLは、URLの＆を&としてエンコードする必要があります。適切なブラウザと賢明なボットが正しく作成され、ソースコードでhttp://example.com/?a=1&b=2にリンクするときに/?a=1&b=2を意味することがわかります。他のhrefを文字通り取得することは問題を示しませんが、それらを文字通り取得することは、あなたが説明していると思う動作を示します。

要求された場所には存在しないが、他の場所に存在するページに対するあらゆる種類の要求を受け取ります。これは通常、ボットがベースパスなどの処理を行えなかったためです（OpenCartでは使用されません）何らかの理由で）または絶対URLまたは他のホスト上のURL（ホストではなくパス部分を取ります）。

1つの良い指標は、IPでrDNSルックアップを実行することです。それらの1つ以上がWebホストに解決される場合、誰かがボット/ダムスクリプトを実行しています。

1
IBBoard