Problema no CORS ArcGIS 10.1 IIS (compartilhamento de recursos de origem cruzada)

Eu tenho o ArcGIS 10.1 instalado com o adaptador da web para o IIS. Adicionei um arquivo de configuração à raiz do IIS7 para habilitar o CORS (Cross Origin Resource Sharing) conforme esta página. Coloquei o servidor ArcGIS habilitado para cors na lista de servidores cors padrão, conforme esta página:

esri.config.defaults.io.corsEnabledServers.push("vmagstenone")). 

No entanto, quando meu aplicativo JavaScript hospedado no vmagsten faz uma solicitação ao servidor GIS (vmagstenone), recebo o erro

"Origin http://vmagsten is not allowed by Access-Control-Allow-Origin.". 

Editar: E a camada do recurso falha ao carregar. Eu também tentei carregar uma camada dinâmica e isso também falha com o mesmo erro _557 (veja a imagem)

Editar: eu não deveria estar vendo esse erro, pois as etapas acima devem significar que o servidor oferece suporte à origem cruzada. Esta declaração da esri de que esse erro pode ser ignorado não se aplica nesse caso, pois esse servidor deve suportar cors. Isso significa que o primeiro erro no servidor ESRI pode ser ignorado.

!

Editar: aqui está um exemplo de resposta de uma consulta nessa camada, mostrando que a resposta tem acesso-controle-permissão-origem

!

Você mencionou que recebeu o erro, mas o serviço realmente falha ao carregar?

Eu pergunto, quando vi este post nos fóruns da Esri, que afirma:

Este erro pode ser ignorado com segurança. Há casos em que a API não envia uma solicitação para // rest / info e é a seguinte: O navegador não suporta CORS O servidor já está listado em esri.config.defaults.io.corsEnabledServers esri.config.defaults.io .corsDetection é false JSON é usado em vez de JSONP nos seguintes casos: O recurso que está sendo buscado está no mesmo domínio que o aplicativo O recurso que está sendo buscado está em um servidor que suporta CORS

Estou assumindo que isso acontece em outros consoles do navegador também?

Caso contrário, você pode lançar um log do Fiddler ou um arquivo .HAR on-line em algum lugar (ou me enviar um e-mail) e editar esta resposta adequadamente.

Embora a resposta contenha um Access-Control-Allow-Origin: *cabeçalho, ela também contém X-Frame-Options: SAMEORIGINe X-XSS-Protection: 1; mode=blockcabeçalhos. Estes são cabeçalhos de prefixo X, que não são padrão , por isso não tenho 100% de certeza se o seu navegador os está honrando sobre o cabeçalho de permissão.

Você pode usar uma ferramenta como o Fiddler para adicionar e remover cabeçalhos das solicitações do navegador; isso pode ajudá-lo a rastrear o que está acontecendo.

Aqui está o que funcionou para mim no IIS 8.0. Isso pode ser diferente em outras versões do IIS.

Remova o arquivo customHeadersdo diretório raiz do site web.configou exclua-o web.configcompletamente.

Em seguida, alterne para ApplicationHost.configno Gerenciador de configuração do IIS do arcgisaplicativo e adicione Access-Control-Allow-Originnome e *valor ao arquivo customHeaders.

Não estou familiarizado com o compartilhamento de recursos entre origens.
Eu uso a política entre domínios.

Você tem isso configurado também?

O que finalmente funcionou para mim foi adicionar o seguinte ao site ROOT e NÃO o aplicativo para o adaptador da web . Isso faz sentido? Não para mim. Mas funcionou para mim.

EDIT: Isso deve ir no arquivo proxy DotNet chamado Web.config.

<configuration>
  <...rest of file...>
    <system.webServer>
      <httpProtocol>
       <customHeaders>
         <add name="Access-Control-Allow-Origin" value="*" />
       </customHeaders>
      </httpProtocol>
    </system.webServer>
  </...rest of file...>
</configuration>