non accurate form_factor matching

I have this HTTP request, I expected this, but WURFL is returning that. Please provide enough data to reproduce the problem.
Posts: 2
Joined: Mon Jan 22, 2018 4:49 am

non accurate form_factor matching

Postby osnat » Mon Jan 22, 2018 5:25 am


using the latest wurfl.xml & API.

we have a set of UAs that are identified as "Desktop" (using the form_factor capability)
for example, take a look on the list below. all of them were identified as "desktop".
from a quick search those are http clients implemented in different languages, that can, theoretically be implemented both on mobile, tv, or desktop. for example, okhttp is a android & java http client.

Apache-HttpAsyncClient/4.1.3 (Java/1.8.0_20)

is it intentionally ? personally, we prefer to set form_factor rather than giving incorrect values.

Posts: 242
Joined: Wed Dec 09, 2015 12:39 pm

Re: non accurate form_factor matching

Postby aaronp » Mon Jan 22, 2018 11:48 am


As mentioned in our other thread, we will likely modify the behavior with all the provided user agents to work similarily to the Go-http-client/2.0 user agent as we would consider all these as spiders/content-fetchers. They will be identified as robots for the form_factor virtual capability in the next API release.



Who is online

Users browsing this forum: Bing [Bot] and 1 guest