referrer strings are handled at the browser.
Exactly. It is the users browser that sends the HTTP referer[sic] as part of the HTTP request. Website.com (where the link originates) has no control over this. In fact, the user has complete control over this.
The HTTP referer is notoriously unreliable. The user can configure their browser to not send a referer ...
I'm afraid you have misunderstood the function of the tag.
<meta name="google" value="notranslate">
only prevents google from showing the 'translate this page option' in their search results, it has no effect on Chrome's translation functionality.
If you specify the page language correctly, Chrome won't offer to translate the page for users with ...
In Apache2, and it should be enough since Tomcat should just pass the data along, you can add a MIME type based on file extensions. This is done with the AddType command:
AddType text/plain .inp
AddType text/plain .trg
Note that if you dynamically generate these files, then setting the Content-Type: ... header is your solution.
Your friend in this kind of situation is cURL.
A really really quick tutorial...
Use curl's view headers only option (-I) to see what headers the server returns on your published domain:
curl -I http://www.nulc2012.com/
I got this response, which says that a Permanent Redirect 301 is being sent to the browser, along with the target URL:
HTTP/1.1 301 ...
Doctype and Microdata shouldn't create many problems. It's possible that it will throw IE into 'quirks' mode, but you will probably be fine.
The problem with HTML5 tags like header and article are that older browsers don't recognize them as block level elements. So if you are using them in that way at all you may be in for some layout surprises.
There are ...
You are correct, some older browsers like Internet Explorer 8 provide little to no support for HTML5 elements and other HTML5 features. There are online sites which can help you identify what's missing in IE 8 and older browsers, such as this one.
There are also open-source projects like this often-cited one, aimed at improving HTML5 compatibility for IE 8:
For initial testing in IE this may be sufficient, but there will always be some differences between how a site loads in an emulator to the real thing. The amount of testing you do should really be strategically influenced by the target user base and the amount of traffic the site receives.
By using a web analytics tool such as Google Analytics or Piwik (...
In attempting to connect to googlesyndication.com over HTTPS, IE failed to load the SSL libraries in the browser required to make the connection. The HTTP connection was successful, returning status 200, but the HTTPS connections failed. Microsoft explains the error as such:
While there are differences, there is not much that cannot be made compatible in older browsers depending upon what you are doing.
If you are developing your site and wanting to add features but feel hampered by the lack of advance in the use of newer versions of a browsers, then you have to decide what you are really doing. For example, if you are ...
The answer to your question is not that simple and depends on various factors, I'll explain:
1. Features - Are your users going to lose part of the functionality of your site because they are on an old browser? if yes, tell them to update.
2. Audience - Are the audience of your site likely to use an old browser? (ex.: elderly specific content, broad ...
It's not. Compatibility mode is just emulation and not the browser versions themselves. I occasionally run into differences that aren't noticed till I look at it on a test system.
Microsoft did come out with VMs that you can install on Windows that do contain the real versions of older IE.