All popular browsers' user agent strings, even Internet Explorer's, start with Mozilla/. Why is this the case?
It is a long and sad story.
In summary:
Mozilla browser gets released, with User-Agent Mozilla/1.0 (Win3.1). It is publicly renamed to Netscape, but in its User-Agent it keeps its original name .
Internet Explorer is released. It spoofs Netscape by starting its User-Agent with Mozilla/ because web servers were routinely browser sniffing and serving pages with frames - a feature supported by both Netscape and IE, but not other browsers of the era - to Netscape only.
Over time, Gecko, Konqueror, Opera, Safari and Chrome each decide to similarly spoof the User-Agent of some previous browser in order to manipulate browser-sniffing web pages into correctly understanding their browser's features. As part of this spoofing, all the browsers start their User-Agents with Mozilla/, like the browsers before them had done. Plenty of other nonsense also results, like modern Chrome's User-Agent simultaneously claiming to be Mozilla, Chrome, Safari, and 'like Gecko'.
I think it had to do with: http://en.wikipedia.org/wiki/User_agent#User_agent_spoofing
Back in the early days, Netscape (code named Mozilla) was the main rival of IE, and they wanted to prevent being rejected by sites rejecting browsers other than Netscape.
As mentioned by #Jason "Its a long story". Summing that story up "its just every browser pretends to be Mozilla"
After trying everything, I have finally used: http://www.useragentstring.com/
You can use the above website to get the formatted user agent and OS.
They have an API which you can use directly...
Reason for this are the infamous browser wars.
In short - browsers started to pretend to be some other browser, because some websites served content based on which browser asked for it and they also wanted content meant for other browsers.
I find it surprising it still haven't been solved to this day. Since userAgent can't be safely removed for legacy reasons, why some new feature clearly identifying a browser wasn't introduced? Yes, most of the time you don't need browser detection, but rather a feature detection, but it is not built-in JS neither!
Because that's how Netscape identified itself, and Microsoft wanted to work with sites that would detect Netscape and reject anything else.
Mozilla/5.0 is the general token that says the browser is Mozilla compatible, and is common to almost every browser today.
for more detail click here
Related
I've been curious to try switching to Firefox Quantum from Chrome, but for web development have hit a major obstacle that I have not been able to easily resolve –– it's caching my localhost files so when I attempt to load various ember applications at localhost:4200 I end up viewing a cached application different than the one that is currently running.
Is there a way to disable caching for localhost in Firefox? And/or how to developers normally work with Firefox in this regard?
And/or how to developers normally work with Firefox in this regard?
I tend to use CTRL + F5 to do hard reload (ignores cache). Pretty standard for all browsers.
Since there is no native way to configure for individual domains, you could write a Browser Extension that can intercept responses via the webRequest API (see for example onHeadersReceived) by overriding cache headers for a selected domain (you may even be able to find one already in existence).
Or simply configure settings in developer tools to ignore cache when toolbox is open:
There is also the Forget Button that can be dragged into the toolbar from customize.
Set the HTTP Cache-Control response header to max-age=0 in your application.
(Edited, I had 'in 2016' but it's not 2016 yet. I meant 'currently')
Things that haven't worked for me so far:
Looking at web console functionality in Firefox (I may be blind)
Looking at web console documentation at mozilla.org - web console doc (the video won't play; I may be missing it. People say it's in the web console but I don't see any headers in the web console. I expect to see meta tags, and redirects in particular are driving me nuts at the moment.)
Tried a couple expired addons in Firefox (there's a fix claimed but I doubt it works yet - search for addons at mozilla.org
Open the Developer Tools. Select the Network tab. Click on the item you wish to examine the headers for.
You won't see any meta tags though since they are not HTTP headers but are part of the HTML document that could be delivered in the response body.
We have deployed an MVC 3 website on an IIS6 box.
Everything runs fine, but the performance is abysmal.
Can anyone help me understand
why am I getting 20 second response times to get a script bundle?
why bundled scripts are not cached by IE even if the Expires header is set?
The site is several times faster in Chrome (I have noticed the cache behaviour is correct), but we cannot force customers to use it.
Any help would be great. I'm kind of wondering if it's a server-side setting that's forcing the bundle recompilation each request, or if it's just IE acting like usual.
Edit: as per comments request, I'm including also the bundle request headers:
If you have different download times for a full reload between the two browsers it could be that you are doing intense computations with a client side framework like angularjs (I have seen big performance differences from highly complex angularjs apps between the two browsers).
If both your browsers show the same download time, it is either a network issue, or a server issue.
The IE caching could be a separate issue, break your problem into two parts - look for the cause of the slow downloads first.
All I can do now is suggest an approach to finding the issue.
Summary of what you know
It looks like you have:
Server sends an Expires header one year from now
When you reload the page (i.e. you don't force a full refresh using Ctrl+F5)
IE doesn't take any notice of the cache header, and when it sends it's new request it doesn't use If-Modified-Since or If-None-Match
Chrome behaves differently and respects the Expires and/or ETag response headers (it doesn't even make the request again for the bundle).
EDIT 1: You also seem to be saying (though it would be good to see a timeline from chrome) that Chrome downloads the files faster, implying it is not a server-side problem. Your latest comment states that Chrome's downloads are also slow. (end edit)
And you also seem to be saying that this behaviour is consistent (i.e. 100 requests in IE, and 100 requests in Chrome show the above behaviour with no deviations).
Approach
You should break this problem into two parts:
Why is the download so slow?
Is there a server-side performance problem? Look for common download times in IE and Chrome, and Firefox (it could be due to bundling/minification/compression on the server).
Is there a network connectivity issue (dropped packets, for instance)? Look for inconsistent download times, Start times, Request times, between requests in a given browser and the same behaviour across all browsers.
Is a script slowing down IE, but not Chrome (this is not uncommon, I maintain legacy sites where the scripts don't run well in IE but do in Chrome) - look at different profile results between browsers.
Why is the javascript not being cached in IE? Troubleshoot (1) first, then worry about this.
It is possible that the two are related, but approaching them separately will be a start. Number 1 is far easier to diagnose that 2, the top references to caching javascript in IE on the web are to prevent it in order to help with development.
Root cause diagnosis
EDIT 1 The first thing to do is try the site from a browser on the server, or very close to the server to see if you have a network issue. (end edit)
Tools like Fiddler, the browser developer tools, timeline and script profiler, and YSlow are your friend. Compare each of the following between Chrome and IE (and see what happens in Firefox as well) and spot the difference. Note: you may need to clear the browser cache between tests.
browser developer tools -> script profile: see if you have a slow running script in IE compared to Chrome
similar analysis in a tool like YSlow (look for comparisons between the two browsers, not script improvements)
request and response headers, and timeline from a normal (i.e. not full reload) page load
request and response headers, and timeline from a full page reload (Ctrl+F5)
Start and Request durations for every js file for a given browser, and between browsers (this may point to network issues)? I note that the Start and Request alone are taking 0.6s and 1s each in IE - that is very very poor performance.
5 requests, and 5 full reloads with cache clearing between (that is, don't chase a ghost - be consistent in your test methodology)
Download times should be no different between Chrome and IE with no scripts actually running so also add a control test. Assuming that your bundle files don't "do anything" (i.e. they contain functions that the page calls rather than kicking off long processes by themselves) then create a blank page in your site which references exactly the same javascript files - not just the bundle, but every single js reference.
With the control test you can compare pure download times and caching behaviour in IE to Chrome, without any client side javascript running (use the developer tools profiler to verify no scripts are running). If your bundle files do kick off long running things, just temporarily disable those things by putting return statements at the top of the script and concentrate only on the download into the browser.
After running the YSlow plugin on a site, I saw that one of the recommendations was to add far future expires headers to the scripts, stylesheets, and images.
I asked a different question about how to set this up in IIS, but I am actually just curious about how each browser behaves.
I have read that IE will cache items per browsing session, so once you reopen the site after closing the browser, it will need to reload all of the content. I believe that Firefox will go ahead and set a expiration date on its own. I have also heard that IE does not cache at all when connecting over HTTPS. I am not sure if these are at all accurate, though, and was wondering if someone could clear up any misconceptions I may have. Thanks!
You are right about Firefox setting its own expiration date. See the second item in this blog post:
http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/
IE, like Firefox, can cache HTTPS based content. However, you need to set Cache-Control: public for persistent caching across browser sessions in Firefox. See Tip #3 in this blog post:
http://blog.httpwatch.com/2009/01/15/https-performance-tuning/
In my post here, I made mention of having an issue with a custom URL protocol link being sent in an email. I got around that issue by sending a link to a web page, which then did the redirect to the custom URL protocol (presumably the issue with sending the direct link was that Gmail (and possibly other providers) were seeing my protocol as "unsafe" and therefore stripping it out of the email).
This is fine and dandy, except in IE8 (I'm unsure about IE7). If I go to that page in FF3 and Chrome, it opens my program as I would expect. In IE8, I just get a generic "Internet Explorer cannot display the webpage" error. Does anyone have any idea why IE8 won't prompt me to run the program?
Custom URL's are often considered dangerous or insecure content in the modern web universe. Your experience with gmail is an example. Many browsers have designs that limit or block URL schemes they do not recognize. The error page might be IE8's default behavior. I have not had much luck with researching my IE8-specific issues, so someone else will probably have to fill in the blanks. (Wiki flag is ON).