Koozali.org: home of the SME Server

browscap.ini directive

Offline piran

  • *****
  • 502
  • +0/-0
browscap.ini directive
« on: August 05, 2009, 01:10:03 PM »
FWIW browscap is apparently a way of deriving browser information.

Does anyone have anything interesting on the [browscap] entry of php.ini?
Is it in general use nowadays? Much of what I am finding is quite old
however the basic data source for it seems to be being maintained:
http://code.google.com/p/phpbrowscap/

I came across browscap while searching for ways to resolve an apparent
difficulty that some .gov visitors were having browsing my site. The logs
showed that all GETs for JavaScript beared UAs carrying additional quite
complex data strings which I presume to be markers (purpose unknown):
Code: [Select]
.CSS file ~ Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; InfoPath.2)
.JS files ~ Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; InfoPath.2) +sfgRmluamFuX1R5cGU9amF2YV9zY3JpcHQmRmluamFuX0xhbmc9dGV4dC9qYXZhc2NyaXB0+
A Google search on that strange code string didn't clarify much other
than a suggestion that it may be a mechanism to throw cache. I noticed
though that others too were apparently seeing this string against .js files.
ISP or proxy insertion? Whatever. The resultant issue was that the string
was provoking a 403 forbidden response from my SME, probably from one
of my many httpd.conf filters all of which will remain just so. The event
did clearly underline the complete absence of any proactive JS detection
on my part and it was this that started off the whole exercise.

I tried a number of methods which included the attempted use of browscap,
various snippets of JS and also simple <noscript></noscript> tags. Lots of
confusion, variant browser responses, multiple JS conflicts later (it took a
day of messing about) finally ended up with the best universal compromise.
FWIW it was using a JS clause and learning how to cope with multiple onloads.

That still left the mechanism known as [browscap]... the subject of this
discussion thread, which I think I would like to have available just in case.

Does anyone have any thoughts, HOWTOs or RPMs to offer or share?

Offline cactus

  • *
  • 4,880
  • +3/-0
    • http://www.snetram.nl
Re: browscap.ini directive
« Reply #1 on: August 05, 2009, 01:16:41 PM »
The resultant issue was that the string
was provoking a 403 forbidden response from my SME, probably from one
of my many httpd.conf filters all of which will remain just so.
And you are 200% positively sure it can not be the result of your filtering?
Be careful whose advice you buy, but be patient with those who supply it. Advice is a form of nostalgia, dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts and recycling it for more than its worth ~ Baz Luhrmann - Everybody's Free (To Wear Sunscreen)

Offline piran

  • *****
  • 502
  • +0/-0
Re: browscap.ini directive
« Reply #2 on: August 05, 2009, 01:29:09 PM »
This one?
Code: [Select]
<Location>
  SetEnvIfNoCase User-Agent "([A-Z][a-z]{3,}|[a-z]{4,}|[a-z]{4,})" UA_BANNED
  Order Allow,Deny
  Allow from All
  Deny from env=UA_BANNED
</Location>
The 403s going out in response to the very strange input is not
a particular concern of mine. If they want to send such strange
GETs then they ought to expect a few 403s. My site's fallback
from 'your JavaScript is disabled' is excellent and transparent
albeit making operations less seamless and fancy. My own
concern was that there was no onscreen indication to the
visitors that a fallback had occurred and stuff was impaired.

Offline piran

  • *****
  • 502
  • +0/-0
Re: browscap.ini directive
« Reply #3 on: August 05, 2009, 03:39:11 PM »
And you are 200% positively sure it can not be the result of your filtering?
I am only 100% sure that SME sent out a 403 forbidden flag as a
result of my filtering ie the httpd.conf clause (as in other posting).

You're clearly a person that likes to dot the i's and cross the t's,
despite an unfeasible use of maths, here is some corroboration:
* the active part of the UA is that end bit between the ++
* reverse testing back to my site and switching in/out the
  quoted part of httpd.conf clause proves to be responsible
Probing a little deeper reveals a possible match...
Code: [Select]
+sfg<Rmluam>FuX1R5cGU9amF2YV9zY3JpcHQmRmluamFuX0xhbmc9dGV4dC9qYXZhc2NyaXB0+
First match Rmluam at position 5
Additional matches:
Found Rmluam at position 37
Found xhbmc at position 47
And, yes, I think the actual regex is malformed though the
same matches do result after removing the code duplication.

I haven't found out quite why the extra string is apparently
injected or by whatever facility (browser, ISP or proxy). My
SME will continue to block any such GETs. Elsewhere the
site now nicely spits out an obvious declaration of a
lack of JavaScript and its associated functionality.

To get this thread back ON TOPIC I trust that the thread
can now resume with any interesting [browscan] snippets.