Re: Does WURFL correctly recognise MSIE?
I'm using pywurfl 7.1.0 to access the WURFL data.
I've compared the code in pywurfl to the Java code here https://dev.wurflpro.com/svn/wurflpro/wurfl-api/java/core/trunk/src/main/java/net/sourceforge/wurfl/core/handlers/matchers/AbstractMatcher.java and it looks like both behave the same.
Is that code the latest, or is there later code accessible somewhere?
--- In email@example.com, fanta <fantayeneh@...> wrote:
> Hi Malcolm,
> which version of the api are you using. Try using the latest api(1.0.1)
> On 5 Jul 2010, at 15:28, Malcolm Box wrote:
> > Hi,
> > I'm using the latest download WURFL (June 3rd) + web browsers patch
> > but not seeing correct identification for MSIE UA strings.
> > E.g. Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET
> > CLR 2.0.50727) is mapping to generic_web_browser, not msie.
> > Looking at the contents of the patched WURFL file, there's an entry:
> > <device user_agent="Mozilla/4.0 (compatible; MSIE 6.0;"
> > fall_back="msie" id="msie_6">
> > <group id="product_info">
> > <capability name="model_name" value="6.0"/>
> > </group>
> > Which looks to me like it should be picked up from the UA string
> > given, and therefore msie returned as the devid.
> > However, testing via the TeraWURFL lookup and via pywurfl 7.1.0 
> > always gives generic_web_browser and not msie.
> > Detection of Firefox works correctly, and following through the
> > matching logic it looks to me that this is because the user_agent
> > strings for Firefox are stripped of the start section ("Mozilla/4.0
> > (compatible") so they match with the normalized UA. However because
> > the MSIE strings are *not* normalized in the XML, they don't match
> > the normalized versions in AbstractMatcher::applyConclusiveMatch() -
> > so MS IE ends up being picked up in the CatchAllRecoveryMatch -
> > which gives us "generic_web_browser".
> > Is this a problem in the Java version, in the web_browsers_patch, or
> > in pywurfl?
> > Cheers,
> > Malcolm
> >  well it does for pywurfl once another bug has been fixed that
> > made it always pick "generic"