Internet Explorer 11이 작동하지 않는 메타 태그를 통해 "호환성보기에서 인트라넷 사이트 표시"를 비활성화합니다.
doctypeInternet Explorer가 이전 브라우저 버전을 에뮬레이트하지 않도록 강제하기 위해 아래 html5 및 Edge 호환성 메타 태그를 사용하고 있었기 때문에 6 개월 이상 인트라넷 웹 사이트에서 작업 해 왔습니다.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>My title</title>
<meta http-equiv="X-UA-Compatible" content="IE=EDGE" />
</head>
<body>
</body>
</html>
내가이 방법을 사용하는 이유는 내가 일하는 곳에서 정책 설정을 사용하여 모든 인트라넷 사이트에 대한 호환성보기를 활성화하고이 EDGE설정을 사용하는이 접근 방식이 Internet Explorer 9에서 작동했기 때문 입니다.
한 달 전에 Internet Explorer 11로 업그레이드했지만 사이트는 여전히 예상대로 작동했습니다.
오늘 이것은 예상대로 작동을 멈췄습니다. 확실히 말할 수는 없지만 IE11에서는 호환성보기를 강제하는 정책이 활성화되지 않았으며 지금은 ...이 활성화되었으므로 호환성 메타 태그가 더 이상 사용되지 않는다고 생각합니다. 이 사이트는 IE8을 에뮬레이트하는 엔터프라이즈 모드에서 실행되고 있습니다.
누구든지이 문제를 해결하고 호환성 "엔터프라이즈 모드"가 적용될 때 인트라넷 사이트에서 IE11을 강제로 사용하는 방법을 알고 있습니까? 브라우저 설정을 통해 비활성화 할 수 없습니까?
편집하다
이 답변 https://stackoverflow.com/a/18257208/98706에 설명 된대로 web.config에 사용자 지정 헤더를 추가하려고했습니다.
그리고 이것은 나를 위해 작동하지 않았습니다. 개발자 툴바 콘솔에 여전히 아래 메시지가 나타납니다.
HTML1122: Internet Explorer is running in Enterprise Mode emulating IE8.
It is as if version 8 is being treated as the edge when this intranet compatibility setting is enabled in IE11.
This post: https://www.leapinggorilla.com/Blog/Read/1016/ie-ate-my-css---disabling-compatability-mode explains this well, I haven't yet tried setting this header via code and our users dont have access to change their browser settings.. none of the other changes have worked as yet.
UPDATE
Please see my comment on this post about what the difference between Enterprise mode and compatibility mode is, because it is important.
Make sure:
<meta http-equiv="X-UA-Compatible" content="IE=edge">
is the first <meta> tag on your page, otherwise IE may not respect it.
Alternatively, the problem may be that IE is using Enterprise Mode for this website:
- Your question mentioned that the console shows:
HTML1122: Internet Explorer is running in Enterprise Mode emulating IE8. - If so you may need to disable enterprise mode (or like this) or turn it off for that website from the Tools menu in IE.
- However Enterprise Mode should in theory be overridden by the X-UA-Compatible tag, but IE might have a bug...
This problem is generally caused by the website/intranet URL being placed in one of:
- Compatibility Mode List
- Internet Explorer Intranet Zone
(with Display intranet sites in Compatibility View setting enabled) - Enterprise Mode List
On corporate networks, these compatibility view settings are often controlled centrally via group policy. In your case, Enterprise Mode appears to be the culprit.
Unfortunately setting META X-UA-Compatible will not override this.
For End-Users
Sometimes the only way for end-users to override this is to press F12 and change the Document Mode under the Emulation Tab. However this setting is not permanent and may revert once Developer Tools is closed.
You can also try to exclude your site from the Intranet zone. But the list of domains which belong to the Intranet zone is usually also controlled by the group policy, so the chance of this working is slim.
To see the list of domains that belong to the Intranet zone, go to:
Tools -> Internet Options -> Security -> Sites -> Advanced
If the list contains your subdomain and is greyed out, then you will not be able to override compatibility view until your network admin allows it.
You really need to contact your network administrator to allow changing the compatibility view settings in the group policy.
For Network Admins
Loading the website with Developer Tools open (F12) will often report the reason that IE is switching to an older mode.
All 3 settings mentioned above are generally controlled via Group Policy, although can sometimes be overridden on user machines.
If Enterprise Mode is the issue (as appears to be the case for the original poster), the following two articles might be helpful:
- How to Enable and Use Internet Explorer 11’s Enterprise Mode [HowToGeek]
- Turn on Enterprise Mode and use a site list [TechNet]
For those who are building an ASP.NET MVC project, make sure that you add the:
<meta http-equiv="X-UA-Compatible" content="IE=edge">
tag into your Layout (template) page. I just spent two hours debugging and tweaking, only to realize that I had only added that meta tag into my child pages. As soon as I added it to my layout page, the browser loaded in EDGE mode perfectly.
The marked answer is the correct one. However, Pricey, you should follow up on this with your AD and desktop admin groups. They are misusing the IE11 Enterprise Mode site list. Microsoft does NOT intend it to be used for all intranet sites within an organization at all. That would be propagating the existing "render all intranet sites in compatibility mode" setting that is the bane of corporate website advancement the world over.
It's meant to implemented as a "Black list", with the handful of sites that actually require a legacy browser mode listed in the Enterprise Mode list with their rendering requirements specified. All other sites in your organization are then freed up to use Edge. The people in your organization who implemented it with all intranet sites included to start with have completely misunderstood how Enterprise Mode is meant to be implemented.
This is an old problem with some good information. But what I just found is that using a FQDN turns off the Compat mode in IE 9 - 11. Example. I have the compat problem with
http://lrmstst01:8080/JavaWeb/login.do
but the problems go away with
http://lrmstst01.mydomain.int:8080/JavaWeb/login.do
NB: The .int is part of our internal domain
The question is a bit old but I just solved a very similar problem. We have several intranet sites here including the one I'm responsible for, and the others require compatibility mode or they break. For that reason, site rules default IE to compatibility mode on intranet sites. I am upgrading my own stuff and no longer need it; in fact, some of the features I'm trying to use don't look right in compat mode. I'm using the meta IE-Edge tag like you are.
IE assumes websites without the fully-qualified address are intranet, and acts accordingly. With that in mind I just altered the bindings in IIS to only listen to the fully-qualified address, then set up a dummy website that listened for the unqualified address. The second one redirects all traffic to the fully-qualified address, making IE believe it's an external site. The site renders correctly with or without the Compatibility Mode on Intranet Sites box checked.
Move it to the Trusted Sites zone by either adding it to a Trusted Sites list or local setting. This will move it out of Intranet Zone and will not be rendered in Compat. View.
Add the below property into the web.config file for IIS sites. This worked for me on my intranet in IE11.
<system.webServer>
<httpProtocol>
<customHeaders>
<clear />
<add name="X-UA-Compatible" value="IE=edge" />
</customHeaders>
</httpProtocol>
</system.webServer>
I solved this issue by redirecting the user to the FQDN of the server hosting the intranet.
IE probably uses the world's worst algorithm for detecting "intranet" sites ... indeed, specifying server.domain.tld solves the problem for me.
Yes, you read that correctly, IE detects intranet sites not by private IP address, like any dev who has heard of TCP/IP would do, no, by the "host" part of the URL, if it has no domain part, must be internal.
Scary to know the IE devs do not understand the most basic TCP/IP concepts.
Note that this was at a BIG enterprise customer, getting them to change GPO for you is like trying to move the Alps east by 4 meters, not gonna happen.
For what it's worth, I had the issue as well in IE11:
- I was not in Enterprise mode.
- The "Display intranet sites in Compatibility View" was checked.
- I had all the
<!DOCTYPE html>andIE=Edgesettings mentioned in the question - The meta header was indeed the 1st element in the
<head>element
After a while, I found out that:
- the User Agent header sent to the server was IE7 but...
- the JavaScript value was IE11!
HTTP Header:
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E) but
JavaScript:
window.navigator.userAgent === 'Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; rv:11.0) like Gecko'
So I ended up doing the check on the client side.
And BTW, meanwhile, checking the user agent is no longer recommended. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent (but there might be a good case)
'development' 카테고리의 다른 글
| Docker 컨테이너가 로컬 / 호스트 Postgres 데이터베이스에 연결하도록 허용 (0) | 2020.08.26 |
|---|---|
| 부동 소수점 값이 0과 같은지 확인하는 것이 안전합니까? (0) | 2020.08.26 |
| 글로벌 ::? (0) | 2020.08.25 |
| Android는 P2P 애드혹 네트워킹을 수행 할 수 있습니까? (0) | 2020.08.25 |
| git에서 특정 덩어리를 대화식으로 해제하려면 어떻게해야합니까? (0) | 2020.08.25 |