Conformidade e alterações de segurança no MSXML 4.0 SP2

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 820882
Sumário
importante Este documento descreve as alterações que tenham sido feitas no MSXML 4.0 Service Pack 2 (SP2) que quebra com compatibilidade com versões anteriores do MSXML 4.0. Enquanto a lista foi revisada para precisão técnico pela equipe do Microsoft XML, não interpretam esta lista como uma lista completa ou final de alterações. Potencialmente, alterações significativas adicionais podem existir em alguns casos de uso. Se você suspeitar que tiveram uma alteração significativa no MSXML 4.0 não está documentado neste artigo, contate Support Services (produtos Microsoft) para relatar alteração significativa e para receber suporte técnico adicional.

As seguintes alterações foram feitas no MSXML 4.0 SP2:
Mais Informações

Validação XSD aplica restrição que é definida em um SimpleType Base

Na versão original lançada do MSXML 4.0 e no MSXML 4.0 Service Pack 1 (SP1), o validador de esquema XML não impõe restrições que são definidas na base simpleTypes . Validar os dados no exemplo a seguir XML do documento (Restriction.xml) contra o exemplo de esquema (Restriction.xsd) não dispara os erros nas versões de lançamento originais do MSMXL 4.0 e o MSXML 4.0 SP1 mesmo que o valor do elemento AlphaTestValue contém um caractere (o caractere "-") que é restrito por base AlphaType simpleType :

Restriction.xsd

	<?xml version="1.0" encoding="UTF-8"?>	<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified"> 		<xsd:element name="AlphaTestValue" type="AlphaTypeMaxLength6"/>		<xsd:simpleType name="AlphaType">			<xsd:restriction base="xsd:string">				<xsd:pattern value="[A-Z]*"/>   	 		</xsd:restriction>		</xsd:simpleType>		<xsd:simpleType name="AlphaTypeMaxLength6">			<xsd:restriction base="AlphaType">				<xsd:maxLength value="6"/>			</xsd:restriction>		</xsd:simpleType>	</xsd:schema>

Restriction.XML

	<?xml version="1.0"?>	<AlphaTestValue>ABCDE-</AlphaTestValue>
No MSXML 4.0 SP2, uma correção foi implementada para impor restrições que são definidas na base simpleTypes quando a validação de dados XML. Isso é uma alteração recentes que tem sido implementada para aumentar compliancy com a especificação de World Wide Web Consortium (W3C) XSD. Dados XML que violam restrições que são definidas na base simpleTypes falharem validação no MSXML 4.0 SP2.

DOM: SetAttribute() exibe um erro quando o atributo valor contém caracteres XML inválidos

O método IXMLDOMElement.setAttribute() foi corrigido para gerar um erro quando um valor de atributo especificado contém caracteres inválidos do XML.

Estes são os caracteres XML válidos e intervalos de caracteres (valores hexadecimais) que são definidos pelas especificações de idioma do W3C XML 1.0:
# x 9 | #xA | #xD | [# x 20 # xD7FF] | [# xE000-#xFFFD] | [# x 10000 # x10FFFF]
Isso é uma alteração significativa que tem sido implementada para aumentar compliancy com a especificação do W3C XML. Você recebe uma mensagem de erro em tempo de execução após a atualização para MSXML 4.0 SP2 se você tiver o código que usa a API do DOM setAttribute método para atribuir valores que contêm XML inválido caracteres para atributos XML. Para resolver esse problema, você deve alterar seu código para que você não usar caracteres XML inválidos em valores de atributo.

Importar esquemas são importadas em esquemas incluídas

No MSXML 4.0 SP2, você deve explicitamente importar esquemas que são importadas em esquemas incluídas para que o esquema de pai incluindo pode usar ou pode fazer referência definições de esquema que eles contêm. Por exemplo, isso é verdadeiro se as seguintes dependências entre três esquemas XML separadas estão em vigor:
  • Esquema de um (a.xsd) usa um XSD incluir elemento para incluir esquema B (b.xsd). No contexto do explicação, um esquema é o esquema incluindo e esquema B é o esquema incluído.
  • Esquema B usa um elemento de importação XSD para importar o esquema C (c.xsd)
Se A (a.xsd), em seguida, tenta usar componentes de esquema que são definidos no esquema C sem explicitamente Importar esquema C, a seguinte mensagem de erro de esquema é gerada quando um esquema é compilada:
'< URI de Namespace >' é um targetNamespace inválido URI.
O erro ocorre no MSXML 4.0 SP2 porque A esquema faz não explicitamente esquema C. esquema A importação deve conter um elemento de importação explícita para Importar esquema C explicitamente especificando o namespace correspondente e os atributos schemaLocation . Não é suficiente especificar somente o atributo namespace . Você também deve especificar o atributo schemaLocation de esquema C.

Essa alteração foi feita no MSXML 4.0 SP2 para obter mais compliancy com o W3C XML Schema especificação.

<all> Não É permitido em uma extensão quando o tipo base não está vazio

MSXML 4.0 SP2 evita o uso do <all> partícula de uma extensão de tipo complexo quando o tipo base não está vazio. Quando você tenta usar o XSD <all> partícula neste contexto, você receber a seguinte mensagem de erro quando o esquema é compilado:
<all> não é a única partícula de um <group> ou sendo usado como uma extensão
Este é um esquema de exemplo que ilustra um uso inválido do <all> particle in a complex type extension:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">	<xs:complexType name="DataReader">		<xs:sequence>			<xs:element name="PacketSize" type="xs:integer"/>			<xs:element name="Encrypt" type="xs:Boolean"/>		</xs:sequence>	</xs:complexType>	<xs:complexType name="NetworkReader">		<xs:complexContent>			<xs:extension base="DataReader">			    <xs:all>                                <xs:element name="ServerAddress" type="xs:string"/>                                <xs:element name="ServerPort">                                           <xs:simpleType>                                                 <xs:restriction base="xs:integer">                                                        <xs:minInclusive value="0"/>                                                        <xs:maxInclusive value="65535"/>                                                  </xs:restriction>                                           </xs:simpleType>                                         </xs:element>                                <xs:element name="RecvTimeoutMS" type="xs:nonNegativeInteger" minOccurs="0"/>			    </xs:all>			</xs:extension>		</xs:complexContent>	</xs:complexType></xs:schema>
especificação do W3C XML Schema não permite o uso do elemento XSD todos os ao estender um não-vazia base complexType . Nesse exemplo específico, você pode usar um elemento de seqüência de esquema XSD (<xs:sequence>) em vez de usar oelemento All (<xs:all>) para definir a extensão de conteúdo complexa. Para obter mais informações sobre o que é permitidoregras de extensão de tipo complexo , consulte a especificação de esquema XML.

Restrição de identidade de exclusividade XSD É verificada quando Xsi:type é usado para alterar o tipo de um elemento

A versão original do MSXML 4.0 e do MSXML 4.0 SP1 tinha um bug onde as restrições de identidade de exclusividade em elementos não foram validadas quando os tipos dos elementos foram alterados usando o atributo de xsi: Type de instância de esquema XML. Isso foi corrigido no MSXML 4.0 SP2 para que uma mensagem de erro de validação é gerada.

Por exemplo, quando você tenta validar o seguinte documento Products.xml contra o esquema Products.xsd, você recebe uma mensagem de erro de validação que indica que há uma identificação de produto duplicados nos dados:

Products.XML

<?xml version="1.0"?><Catalog xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">    <products>	<product>		<productID xsi:type="ProductIdType">Prod1</productID>        </product>	<product>		<productID xsi:type="ProductIdType">Prod1</productID>        </product>    </products></Catalog>

Products.xsd

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">    <xsd:element name="Catalog" type="catalogType" />    <xsd:complexType name="catalogType">        <xsd:choice>            <xsd:element name="products">                <xsd:complexType>                    <xsd:choice maxOccurs="100">                        <xsd:element name="product" maxOccurs="unbounded">                            <xsd:complexType>                              <xsd:sequence>                                <xsd:element name="productID" type="xsd:string"/>                              </xsd:sequence>                            </xsd:complexType>                        </xsd:element>                    </xsd:choice>                </xsd:complexType>                <xsd:unique name="unique_part">                    <xsd:selector xpath="./product" />                    <xsd:field xpath="productID" />                </xsd:unique>            </xsd:element>        </xsd:choice>    </xsd:complexType>    <xsd:simpleType name="ProductIdType">        <xsd:restriction base="xsd:string">            <xsd:maxLength value="5"/>                </xsd:restriction>     </xsd:simpleType></xsd:schema>

Segurança é reforçada quando você postar dados usando o ServerXmlHttp objeto

Segurança na implementação do objeto MSXML 4.0 SP2 ServerXmlHttp foi aprimorada para verificar a configuração de diretiva de segurança do Internet Explorer enviar dados de formulário não criptografados. Quando você define a diretiva de segurança de enviar dados de formulário não criptografada para Desativar ou para Solicitar , a seguinte mensagem de erro pode ser gerada quando você tenta executar um POST HTTP usando o objeto ServerXmlHttp :
Acesso negado
Isso é uma alteração que potencialmente pode quebrar o código existente que usa versões anteriores do objeto ServerXmlHttp (MSXML 3.0 e seus service packs atuais, o lançamento original do MSXML 4.0 e MSXML 4.0 SP1) para executar um HTTP POST quando a configuração de diretiva de segurança do Internet Explorer para enviar dados de formulário não criptografados não está habilitada.

Para configurar a segurança do Internet Explorer para permitir o envio dos dados de formulário não criptografada para todos os usuários em um computador, faça as seguintes no Microsoft Windows 2000 e posterior:
  1. Clique em Iniciar , clique em Executar , digite mmc e, em seguida, pressione ENTER.
  2. O arquivo ou a ação menu, clique em Adicionar/remover Snap-in .
  3. Na caixa de diálogo Adicionar/remover Snap-in , clique em Adicionar .
  4. Na guia autônomo , clique em Adicionar . No snap-in autônomo disponíveis caixa de diálogo, clique em Diretiva de grupo e, em seguida, clique em Adicionar . O Assistente de diretiva de grupo é exibido.
  5. No Assistente de diretiva de grupo, clique em Concluir
  6. Feche a janela Adicionar Snap-in autônomo clicando no botão Fechar
  7. Clique em OK na Adicionar/remover Snap-in caixa de diálogo.
  8. Em User Configuration , expanda Configurações do Windows , expanda Manutenção do Internet Explorer e em seguida, clique em segurança .
  9. No painel direito, clique duas vezes em zonas de segurança e classificações de conteúdo .
  10. Em zonas de segurança e privacidade , clique em Importar as configurações de privacidade e atuais das zonas de segurança e, em seguida, clique em Modificar configurações .
  11. Selecione a zona que você deseja modificar e clique em Nível personalizado
  12. Modificar as configurações para habilitar o enviar o formulário sem criptografia dados opção selecionando o botão de opção Ativar para essa opção. Se já estiver habilitado, em seguida, apenas clique o botão OK .

    A zona onde a configuração deve ser habilitada é determinada pela zona onde a URL de destino da operação POST é classificada. Por exemplo, quando você lança para um URL de Internet, você deve ativar essa opção para a zona da internet.
  13. Reinicie o processo que está executando o ServerXMLHTTP. Para fazer isso, talvez você precise reiniciar o computador.
Em um computador que está executando o Windows Server 2003 no modo Internet Information Services (IIS) 6.0, a alteração dessa configuração não tem efeito e você continuar a receber a seguinte mensagem de erro:
Acesso negado
Isso é causado por um recurso de segurança adicional que é chamado “ reforçada configurações do Internet Explorer ”. Em alguns computadores, isso é instalado por padrão. Em outros computadores, você pode adicioná-lo por meio de componentes do Windows usando a ferramenta Adicionar ou remover programas no painel de controle.

Se um bloqueio de segurança adicionais para baixo na conta que executa o IIS6 processo está em vigor, use um dos seguintes métodos para contornar o problema:
  • Método 1: Executar sites especificados, ou diretórios virtuais em um pool de IIS separado e, em seguida, crie um usuário que o pool será executado em.
  • Método 2: Criar uma nova DLL, escrever código para fazer chamadas ServerXMLHTTP e hospedar a DLL de COM + em um novo usuário.
  • Método 3: Usar WinHTTP alterando o identificador de programa de MSXML2.ServerXMLHTTP.4.0 para WinHTTP.WinHTTPRequest.5.1 .
Referências
Para obter informações adicionais, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
818081INFO: Lista de problemas corrigidos no MSXML 4.0 SS (parte 1 de 4)
818083INFO: Lista de problemas corrigidos no MSXML 4.0 SP2 (parte 2 de 4)
818084INFO: Lista de problemas corrigidos no MSXML 4.0 SP2 (parte 3 de 4)
818085INFO: Lista de problemas corrigidos no MSXML 4.0 SP2 (parte 4 de 4)

Propriedades

ID do Artigo: 820882 - Última Revisão: 09/10/2003 23:26:21 - Revisão: 3.1

Microsoft XML Core Services 4.0, Microsoft XML Core Services 4.0 Service Pack 1, Microsoft XML Core Services 4.0

  • kbmt kbxml kbinfo KB820882 KbMtpt
Comentários