Page 1 of 1

User Agent information

Posted: Mon Sep 19, 2011 1:32 am
by sankx
Hi

This is my code snipet:

Code: Select all

public void Device getDevice(HttpServletRequest request, ServletContext appContext){
WURFLHolder wurflHolder = (WURFLHolder) servletContext.getAttribute(WURFLClass);
System.out.println("WURFLHolder Class Name:"+wurflHolder.getClass().getName());
wurflManager = wurflHolder.getWURFLManager();
System.out.println(" Before creating Device, the Request's  UserAgent ======>"+httpServletRequest.getHeader("user-agent"));
Device device = wurflManager.getDeviceForRequest(httpServletRequest);
System.out.println(" After Creating Device, the  UserAgent became =======>"+device.getUserAgent());
return device;
}
And the output of this code is :

Code: Select all

WURFLHolder Class Name:net.sourceforge.wurfl.core.web.ServletContextWURFLHolder
Before creating Device, the Request's  UserAgent ======>Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
After Creating Device, the  UserAgent became=======>DO_NOT_MATCH_GENERIC_WEB_BROWSER

My question is how come 'userAgent' of HttpServletRequest change to other UserAgent i.e. 'DO_NOT_MATCH_GENERIC_WEB_BROWSER' and set to Device object?
Is there any rule within WURFL engine/core that consult wurlfl.xml and change it?

Please please help me on this. What is the logic behind this.

regards
SKC

Re: User Agent information

Posted: Mon Sep 19, 2011 3:34 am
by sm_support2
It's very simple. You are asking the API to return the UA string associated to the device that was matched, not the one that came with the original HTTP request

of course, when the API cannot find a direct match, specialized logic will kick on and identify a generic device that is as close as possible to what the client can do

Re: User Agent information

Posted: Mon Sep 19, 2011 4:30 am
by sankx
Hi

Extremely helpful.
But my intention is to know the logic behind API in details, how it works technically, bit of in pseudo flow
like :

1) Get the UA from request
2) normalize it
3) Match or compare after consulting with wurfl.xml


Sorry, this is just my intuition.
I am just curious to know the logic/rules by looking into src, if you can give some direction. It will be nice if you supply some code-flow considering the above scenario.

Or alternatively if you can tell me, how to set the wurfl Log debuger switch on, so that I can trace full flow in the STDOUT log.

Appreciate your quick and valued response.

regards
SKC

Re: User Agent information

Posted: Mon Oct 29, 2012 12:01 pm
by shgeorge
Hi
I have the same issue. I tried Chrome, IE and FF.
Eg: For FF, UA paased is Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0.
UA returned by the API is DO_NOT_MATCH_GENERIC_WEB_BROWSER and I am not getting any info about OS.
I am using device.getCapability("device_os") and device.getCapability("device_os_version") .

But I am getting values when I try mobile UAs. So does wurfl give information only when it is mobile browsers?

Please let me know .
Thanks

Re: User Agent information

Posted: Mon Oct 29, 2012 12:44 pm
by kamermans
The WURFL APIs have two modes: High-Performance (HP) and High-Accuracy (HA). In HP mode, you will almost always get a generic web browser response for desktop browsers, as some shortcuts are taken for the sake of performance. Note that even in High Accuracy mode, we do not return the device OS information as this can be obtained fairly easily from the user agent.

Re: User Agent information

Posted: Mon Oct 29, 2012 3:14 pm
by sm_support2
Hi Shgeorge,

In addition to what Steve wrote, please keep in mind that the device object contains the user-agent string that is found in WURFL (and not the one originally found in the HTTP request). This may or may not be similar to the one sent by the requesting device.
Since there are so many desktop browsers around, WURFL simply contains its own manufactured token and the logic in WURFL is in charge of doing the match with 'generic_web_browser'.

This works for most, but keep in mind that you also have access to the source code, so a little bit more effort in digging into the code will deliver the ability to tweak the framework for whatever need.

Of course, we are always interested in hearing about the needs of WURFL users. If a use-case is reasonably common and we have the ability to make the feature generic enough, we may support the new use-case in more out-of-the-box ways...

Thanks