-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Like Werner, I have played around with the Java webservice and like Werner, I say : great stuff.
Seeing as I run a very similar service (see below) which currently gets anywhere between 5k to 10k hits per day, I like to share some of the issues I ran into and some points for discussion. 1) user-agent in URL query-string Some servers, in my opinion quite rightly, are configured to refuse requests with 'dodgy' character sequences in their query string (like complete URLs with their own query string), such as may occur in some of the more exotic user-agent strings. Security considerations may also, again quite rightly, be invoked to limit the length of URL and/or query string of a request. In short, including the user-agent string in the query string can justifiably be said to open a potential attack vector on a host. When running tests on the initial version of the web-service, with ua in URL and after relaxing the host's security settings with regard to acceptable requests, every 'script-kid' and his dog tried and kept trying to find a way to break things. The solution I chose and propose : including the ua to be resolved in a custom HTTP header (Ddr-User-Agent), while forcing the requestor to employ a bit more code, has, I think the following advantages : - - forcing the requestor to employ a bit more code -- the template/boilerplate can be made available for various stacks/languages as part of DeviceMap -- adds a bit of 'security thru obscurity' and deprives 'script-kiddies' etc from their 'fun', saving resources (bandwidth and time) as well as avoiding possible security headaches - - the security issues mentioned above are no longer an issue for the host - - the service can differentiate between the ua (and optionally IP) of the requestor and the ua (and optionally original source IP) being presented for resolution (the service would 'read' x-forwarded-for as the IP belonging to the ua in the Ddr-user-agent header, while all other HTTP headers retain their function/meaning) 2) response Judging from the feedback I got, 'clients' prefer to get only those key-value pairs for which a 'real', i.e. non-empty, non-default, value exists. If a key is not present in a response, the client is *knows* it's value and depending on their requirements can then implement their own suitable defaults. This appears to be a significant issue. Others who provide similar web services appear very 'complete' and up-to-date in that they return a value for practically every known property for just about any ua. However, this is regarded as 'cheating' since the 'client' spends time processing responses and basing routing and content/formatting decisions on values of which the value (pun intended) is unknown. Some keys however are expected in *every* response, such as, for example : IsDestop, IsMobile, IsBot,... a time stamp and version info of the data set. 3) 'esthetics' "Les gouts et les couleurs...", I know, but to me an ua in an URL just looks...off. "It's just not cricket" ;-) Finally : the below of (see below) : I have described the service here earlier. It basically uses the DeviceMap, ex-OpenDDR, resolver code and the current DeviceMap data, and it's responses are -- as far as I can tell now -- identical (same device id). I will make the UA's 'harvested' from the web service I mentioned available as soon as possible and with regular updates. I think that to this end we may want to revisit the points raised on the whats and the hows involved. (log date, ua, IP, country,...) What do you think ? esjr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRkIr1AAoJEOxywXcFLKYcUm0H+gP6oYN/dZZU5JNXouRd/40u E7m+CBnWhvBMNacHY+KbojycUmr+GkjbXIdD5IUMoQqfI7Z3wtR62Y0QI3JM+X05 vIP7HGdspe5BpfvQfeuMdu3epbObEP/7ovlfaqg1k3tcX58z3oJBXRH2EYCHtHhz aP9PYMddolyaNlVKvd8vcpovp/HI1wuBqXaPiVcHsuCGqUN2tk5rNhCLaWJNTKJl K1OVeG08UAkQ2b4VFNC2PGOuEmcSA7DMaiISGYVkQHi/0LdHfqYX5bzc1IXrK0qK iRaXA9UgrK9OZ5miztnjbUyIcf5Q+qj5Za42ID0f5YYWoPivcRZW9tgaHB6OFUQ= =0vdz -----END PGP SIGNATURE-----
