ヘッダーを正しく収集して解釈すれば、デバイスについて、そしておそらくユーザー自身についても多くを語ることができます。 この記事では、
Wapstartで httpヘッダーで渡される情報をどのように使用するかについて説明します。
免責事項-この記事は概要です。 いくつかの事柄は、コミュニティにとっては
キャプテン過ぎに見えるかもしれません。
基本から始めます。
原則として、Web内では、相互作用は
httpプロトコルを介し
て行われます 。
GETメソッドを使用した最小の有効なhttpリクエストは次のようになります。
GET / HTTP/1.0\r\n \r\n
または：
GET / HTTP/1.1\r\n Host: wapstart.ru\r\n \r\n
見出しは、フィールド名とその値をコロンで区切ったペアです。 詳細は
rfcをご覧ください。
原則として、ブラウザはいくつかの追加ヘッダーを送信しますが、これはrfcに記述されている場合と記述されていない場合があります。 :)
User-agentヘッダーはほとんど常に渡されますが、プロキシを介して作業している間、viaまたはx-forwarder-forヘッダーも追加されます。 厳密に言えば、rfc
はヘッダーを渡すことを
妨げるものではなく 、単にヘッダーを無視するように言っています。
たとえば、このようなリクエストはまだ有効です。
GET / HTTP/1.1\r\n Host: wapstart.ru\r\n User-agent: dovg\r\n x-ololo: trololo\r\n x-habrauser: dovg\r\n \r\n
ヘッダーは、
cgiプロトコルの rfcで定義されている形式でアプリケーションに届く可能性が高くなり
ます 。 （セクション4.1）
大まかに言うと、プロトコル表示（HTTP）が追加され、大文字に変換され、短所（ハイフン）が下線に置き換えられます。たとえば、x-habrauserはHTTP_X_HABRAUSERになります。 この場合の値は変更されません。
現実の世界では、Opera-miniとNokiaの携帯電話の標準ブラウザに、多くのヘッダーが追加されています。
タスクに戻りましょう。
私たちはモバイルWebでの広告に携わっているため、主要なタスクの1つは、条件付きの「モバイルユーザー」を非モバイルユーザーから分離することです。
もちろん、この問題を100％の効率で解決することはできません。 情報はクライアント側で生成されるため、ユーザーデータを信頼することはできません。
ユーザーの「モビリティ」を定義することに加えて、次のことを知りたいと思います。
- ユーザーのデバイスに関する情報（画面解像度、wifiの可用性など）。
- デバイスを制御するオペレーティングシステム
- 要求が行われるブラウザ（アプリケーション）。
これらのデータにより、よりターゲットを絞った、したがってユーザーにとって興味深い広告を表示できます。
最初の目標-ユーザーの「モビリティ」をどのように理解するかから始めましょう。 むかしむかし、
このような台本を書きまし
た 。
私はphpで実装しますが、ここで使用されるアルゴリズムは非常に単純なので、スクリプトをnginx configに移植することもできます。 ちなみに、nginxレベルでこれを行うことを考えていましたが、私たちの手はその実装に達しませんでした。
この記事では、コードは提供しません。githubにあります。 重要な発言-1つのユーザーエージェントのみを完全に信頼することはできません！
他のタスクについては、gdiデータベース（Get Device Info）を思い付きました。これは現在、一連のhttpヘッダーからデバイス、OS、およびブラウザーに関する情報を取得できます。
私たちにとって、インターフェースは次のとおりです-
get header:HTTP_ACCEPT_ENCODING=gzip%2C+deflate&HTTP_USER_AGENT=Opera%2F9.80+%28J2ME%2FMIDP%3B+Opera+Mini%2F6.24093%2F27.1324%3B+U%3B+ru%29+Presto%2F2.8.119+Version%2F11.10&HTTP_X_OPERAMINI_FEATURES=advanced%2C+file_system%2C+camera%2C+touch%2C+folding%2C+routing&HTTP_USER_AGENT=LG+%23+KP500&HTTP_USER_AGENT=LG-KP500+Teleca%2FWAP2.0+MIDP-2.0%2FCLDC-1.1 VALUE header:HTTP_ACCEPT_ENCODING=gzip%2C+deflate&HTTP_USER_AGENT=Opera%2F9.80+%28J2ME%2FMIDP%3B+Opera+Mini%2F6.24093%2F27.1324%3B+U%3B+ru%29+Presto%2F2.8.119+Version%2F11.10&HTTP_X_OPERAMINI_FEATURES=advanced%2C+file_system%2C+camera%2C+touch%2C+folding%2C+routing&HTTP_USER_AGENT=LG+%23+KP500&HTTP_USER_AGENT=LG-KP500+Teleca%2FWAP2.0+MIDP-2.0%2FCLDC-1.1 0 234 O:12:"CuttedDevice":6:{s:5:"*id";i:3027;s:7:"*name";s:5:"KP500";s:10:"*deleted";b:0;s:9:"*parent";O:18:"CuttedDeviceParent":2:{s:5:"*id";i:23;s:7:"*name";s:2:"LG";}s:14:"*screenWidth";i:240;s:15:"*screenHeight";i:400;}
このレポートで、devconfの相互作用について詳しく学びたいと思います。
まだ解決できない既知の問題：
- Appleデバイス（Iphone、Ipad、Ipod）は、オペレーティングシステムのバージョンに関する情報のみを送信し、デバイスのモデルに関する情報は送信しません。 言い換えれば、標準のブラウザからhttpリクエストがある場合、どのIphoneが作成されたかを言うことはできません。 送信されるヘッダーに関しては、3gsと4gは同じように見えます。 はい、これはjsで解決できることがわかっています。
- 一部のopera-miniアセンブリは、電話に関するすべての情報をカット（置換）します。
そして最後に、私たちのデータベースの見出し統計：
gdi=> select count(distinct name) from request; count
gdi=> select count(*) from request; count
gdi=> select name, count(value) as different_values from request group by name order by different_values desc limit 10; name | different_values