This question already has answers here:
Why do all browsers' user agents start with "Mozilla/"?
(6 answers)
Closed 4 years ago.
When I myself send many requests to the server I found it amazing that in IE if I choose opera user string that the value of user string was
User-Agent Opera/9.80 (Windows NT 6.1; U; en) Presto/2.2.15 Version/10.00
But if I choose another browser in Internet Explorer that it puts Mozilla 5.0 in the user string first.
When I send the ajax request from Chrome that I found same thing that they put user string
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.20 (KHTML, like Gecko) Chrome/11.0.672.2 Safari/534.20
I found that Mozilla is an organization that doesn't have anything to do with Google and Microsoft. Perhaps it was a competitor for both. Why do MSFT and Google both put Mozilla in their user agent? Is there any reason for putting Mozilla in connection string?
Why do chrome and IE both put Mozilla in the userstring when they send the request? I do not know why but is there any specific reason for that?
See: user-agent-string-history
It all goes back to browser sniffing and making sure that the browsers are not blocked from getting content they can support. From the above article:
And Internet Explorer supported frames, and yet was not Mozilla, and so was not given frames. And Microsoft grew impatient, and did not wish to wait for webmasters to learn of IE and begin to send it frames, and so Internet Explorer declared that it was “Mozilla compatible” and began to impersonate Netscape, and called itself Mozilla/1.22 (compatible; MSIE 2.0; Windows 95), and Internet Explorer received frames, and all of Microsoft was happy, but webmasters were confused.
Related
I've been working on open tracking by attaching tracking pixel to an email which is sent via PHP web application that I've been developing. The first problem I encountered was marking email as open just it was sent. I found help here: False open trackings using SES and gmail where I found link to the article describing how to prevent triggering opens by Google bot by checking user agent. I created the following function to check if I deal with the bot:
function isGoogleBot(string $userAgent): bool
{
$googleBotUserAgent = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.246 Mozilla/5.0';
return $userAgent === $googleBotUserAgent;
}
I also read some articles about caching images by Gmail but unfortunately I'm still dealing with some problems.
I did the following test in Chrome, Firefox, Edge and Safari:
I sent an email via application that I've been working on and then opened it in Gmail web client.
Then I went to the application to see open tracking statistics.
I repeated above test twice to make sure every time I get the same result.
With the last email I checked what is happening with subsequent opens of the same email.
Here are my observations:
In every browser except Firefox when I open email for the first time
an extra open is being made so I see 2 opens in the statistics. In
Firefox only 1 open is numbered.
On subsequent opens only 1 open is being added to the total opens
statistics every time I open the email. The exception is also Firefox
where total opens counter is not changing. No matter how many times I
open the email the total opens count is equal 1.
Is there any solution how to make reliable open tracking in every browser when email is opened in Gmail?
I have a desktop application that uses CEF for displaying a built in web page.
I have customized the User-Agent (Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) DesktopApp MyAppName/1.0 (MyApp release 1.0 stamp 99999) Safari/537.36) but Google Analytics only shows as Safari 537.36.
Are browsers outside the known universe of real browsers supported by GA when looking up browsers used? I would like this to instead be MyApp instead of Safari or Chrome.
I just looked at my browser reports and unless "aaa", "ddd" and "this is a test ua" are actually existing browsers it would seem that GA also tracks unknown user agents.
More seriously, the measurement protocol (on top of which Google Analytics is built) allows for a user agent override parameter (&ua), which probably would make very little sense if you could only pass in known browser names (after all this is meant so support e.g IoT devices which might not even have a real user agent name).
Can someone please explain what "Safari (in-app)" means in Google Analytics under Audience | Technology | Browser & OS?
For the Google Analytics for our website, we suddenly started to see significant traffic from this source.
It sounds like it just means that visitors are coming to us through browsers embedded within apps (e.g. like a web viewing control) except that there doesn't seem to be reason why we should be getting such traffic and so suddenly.
We went from zero traffic from this source to almost 40% of our traffic in only two days for no apparent reason! We haven't done anything that can explain this sudden new source of traffic (e.g. we haven't released any apps ourselves) that point back at our website. We're hoping that, if we can find out what "in-app" actually means, we'll be able to understand this traffic.
Thank you
I did some tests on a separate page available only for me using IOS 8.2 and updated 1Password and Facebook App:
General Safari browser is reported as Safari 8.0:
Mozilla/5.0 (iPhone; CPU iPhone OS 8_2 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12D508 Safari/600.1.4
1Password is reported as Safari 6.0:
Mozilla/5.0 (iPhone; CPU iPhone OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B329 Safari/8536.25
Facebook App is reported as Safari (in-app)
Mozilla/5.0 (iPhone; CPU iPhone OS 8_2 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12D508 [FBAN/FBIOS;FBAV/27.0.0.10.12;FBBV/8291884;FBDV/iPhone7,2;FBMD/iPhone;FBSN/iPhone OS;FBSV/8.2;FBSS/2; FBCR/Play;FBID/phone;FBLC/en_US;FBOP/5]
Tested on 2015.03.31 (yyyy.mm.dd)
Visitors using built-in search box within Safari are now having their searches sent though Google SSL Search, if they use iOS 6. Searches done with Google and through Safari's search box will continue to grow, as people continue to upgrade to iOS 6 (currently for iPhone 4/4S highest version is 6.1.3, for iPhone 5 is 6.1.4). Also Google updated their user-agent parsing code and UA like this:
1Password
Mozilla/5.0 (iPhone; CPU iPhone OS 6_1 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) 1Password/4.1.2 (like Version/10B143 Mobile/6.1 Safari/8536.25)
will be categorised like Safari (in-app).
Read more in the articles below and do not trust Google Analytics fully.
Hope this helps!
iOS 6 change Google traffic from Safari
Safari (in-app) as reported by Google Analytics
As you concluded, many people think those represent traffic from iOS apps opening links not on the browser but inside the app (WebView). However, I haven't being able to find a concrete Google Documentation on that.
As for the sudden increase, it is not unusual. Just yesterday I saw how HTC Hero (#1 Device in visits) went from 25.000 visits/day to 0 in two days, and Elocity A7 A7 Internet Tablet from 0 to 30.000 visits/day at the same time. Seems, Google keeps updating its User-Agent Parsing code.
I noticed it being reported in email tracking. Could it be Email Opens in Safari if you have set up email tracking in GA.
Looks like people accessing your website via a home screen bookmark. "Add to Home Screen" function, rather than via the Safari browser are listed as "Safari (in-app)".
I'm looking at a GA account that only watches iPads displaying a "WebApp". It looks like those devices running 10.3.2 and higher display as "Safari (in-app)" and those below show as "Safari" only.
This would also explain the sudden jump in metrics. As users update their iOS will suddenly be listed as "Safari (in-app)".
When using Simple HTML DOM library I have faced a problem with some websites. When I tried to load the following url http://www.t-mobile.com/shop/phones/cell-phone-detail.aspx?cell-phone=HTC-One-S-Gradient-Blue&tab=reviews#BVRRWidgetID
My PHP code is:
<?php
include "simple_html_dom.php";
$html=new simple_html_dom();
$url="http://www.t-mobile.com/shop/phones/cell-phone-detail.aspx?cell-phone=HTC-One-S- Gradient-Blue&tab=reviews#BVRRWidgetID";
$html->load_file($url);
echo $html;
?>
The php script gives no error but it shows the following content every time.
Unsupported Browser
It appears that you are viewing this page with an unsupported Web browser. This Web site works best with one of these supported browsers:
Microsoft Internet Explorer 5.5 or higher
Netscape Navigator 7.0 or higher
Mozilla Firefox 1.0 or higher
If you continue to view our site with your current browser, certain pages may not display correctly and certain features may not work properly for you.
What is the problem? Does Simple HTML DOM have a limitation? Is there any other way to solve this problem?
Some websites are not allowed to scrap its content directly.
you can use curl fetch html content and then use load() of dom object.
i hope it work for you.
Just setup your USERAGENT in simple_html_dom request:
# Creating useragent array
$useragent = array("http" => "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6");
# Creating a line from array
$useragent = stream_context_create($useragent);
# Starting Simple_HTML_Dom with our useragent
$html = file_get_html($urlCategory, $useragent)
So, our request will be from the newer browser than yours.
set the useragent
$context = stream();
stream($context, array('user_agent' => 'Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6\r\n'));
file_get_html('http://www.t-mobile.com/shop/phones/cell-phone-detail.aspx?cell-phone=HTC-One-S- Gradient-Blue&tab=reviews#BVRRWidgetID', 0, $context);
I've got an app built using ASP.NET MVC 3.0. It uses asp.net's built in forms authentication, without session state, and cookies on the browser to identify the user making requests.
Now, when I'm testing the app using IE9, the typical HTML request sends this user-agent in the header, and everything works fine.
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
However, we have one page in the app that has an ActiveX container that hosts Microsoft Word in the browser. The purpose of this ActiveX container is to allow you to make modifications to the word document, click on a button to POST that word document with your changes to our server so it can be saved.
There is a method in the ActiveX control--Office Viewer Component from www.ocxt.com--called HttpPost() that POSTs the contents of the viewed document to the server.
When you call HttpPost(), it sends all the same cookies properly, but uses a different User-Agent string.
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
The UserAgent using MSIE 5.5 string appears to cause ASP.NET or MVC to not send the request to the appropriate controller, but instead sends a redirect response to the Login page even though the cookie is correct for the session. I did a test with Fiddler, and tried using MSIE 6.0, 7.0, 8.0 and those seem to work fine, so specifically, 5.5 causes part of the server stack to redirect to login page.
This page used to work fine, so I'm not sure if something has changed in recent versions of ASP.NET/MVC, or is it because I've moved up to IE9.0, but basically, I'd like to know if it is possible to tell ASP.NET to not take the User-Agent into account when determining if a session has been authenticated already or not.
Thanks.
IIRC there was a change in ASP.NET 4.0 where Forms Authentication uses the user agent to detect whether it supports cookies and if it is not a recognized or unsupported user agent it simply doesn't use the authentication cookie. You will need to change the User Agent of the HTTP request.
How to disable this default behavior for the webserver to check cookie support on the user agent in the web.config and force cookies for all browsers...
<system.web>
<authentication mode="Forms">
<forms cookieless="UseCookies" />
</authentication>
</system.web>
What's annoying about this default setting is that some valid User-Agent headers on new browsers will cause cookies to be ignored.
this User-Agent's form auth cookie is NOT ignored...
Mozilla/5.0 (iPad; CPU OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3
this User-Agent's form auth cookie IS ignored...
Mozilla/5.0 (iPhone; CPU iPhone OS 6_0_1 like Mac OS X; en-us) AppleWebKit/536.26 (KHTML, like Gecko) CriOS/23.0.1271.91 Mobile/10A523 Safari/8536.25
But adding the cookieless="UseCookies" attribute will tell ASP.NET to use the cookies from anything.