ヘッダーを正しく収集して解釈すれば、デバイスについて、そしておそらくユーザー自身についても多くを語ることができます。 この記事では、 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;} //, memcache ;) // memcache, .
このレポートで、devconfの相互作用について詳しく学びたいと思います。
まだ解決できない既知の問題：
- Appleデバイス（Iphone、Ipad、Ipod）は、オペレーティングシステムのバージョンに関する情報のみを送信し、デバイスのモデルに関する情報は送信しません。 言い換えれば、標準のブラウザからhttpリクエストがある場合、どのIphoneが作成されたかを言うことはできません。 送信されるヘッダーに関しては、3gsと4gは同じように見えます。 はい、これはjsで解決できることがわかっています。
- 一部のopera-miniアセンブリは、電話に関するすべての情報をカット（置換）します。
そして最後に、私たちのデータベースの見出し統計：
gdi=> select count(distinct name) from request; count ------- 134 (1 row)
gdi=> select count(*) from request; count -------- 651655 (1 row)
gdi=> select name, count(value) as different_values from request group by name order by different_values desc limit 10; name | different_values ---------------------------+------------------ HTTP_USER_AGENT | 648494 HTTP_X_WAP_PROFILE | 701 HTTP_X_OPERAMINI_PHONE_UA | 698 HTTP_VIA | 572 HTTP_X_PROXY_ID | 245 HTTP_X_OPERAMINI_FEATURES | 184 HTTP_X_OPERAMINI_PHONE | 109 HTTP_X_MSISDN | 96 HTTP_X_BLUECOAT_VIA | 84 HTTP_X_DEVICE_USER_AGENT | 77 (10 rows)