2009-06-01 7 views
0

J'ai un site Web qui utilise Microsoft Indexing Service pour indexer et interroger un répertoire contenant divers documents de type pdf, rtf, mht et doc. L'indexation et l'interrogation fonctionnent bien (pour la plupart); Cependant, certains fichiers seront chargés tandis que d'autres ne le feront pas.Impossible de parcourir certains fichiers PDF et documents

Ceci est une boîte de Windows Server 2003 exécutant le site en utilisant IIS 6.

Le répertoire indexé est un sous-répertoire hors du répertoire racine du site (à savoir http://my.domain.com/files/).

Les chemins de fichier sont précis dans l'URL; Cependant, je ne peux accéder qu'à certains fichiers de chaque type de fichier. Les fichiers que je ne peux pas accéder donnent un fichier 404 introuvable. Je suis capable d'ouvrir tous les fichiers via Windows Explorer, mais tenter de les ouvrir via un navigateur sur http est aléatoire.

Quelqu'un a-t-il rencontré ce problème et sait comment le résoudre? Quelqu'un at-il une idée de la raison pour laquelle je peux accéder à certains fichiers mais pas à d'autres? Est-ce que quelqu'un a des recommandations sur ce qu'il faut examiner pour essayer ceci (c'est-à-dire le propriétaire importe-t-il ou quelque chose comme ça?)?


EDIT: Voici la demande et têtes de réponse pour un mauvais fichier:

GET /files/file1.pdf HTTP/1.1 Accepter: image/gif, image/jpeg image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/xaml + xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/application x-ms, application/x-silverlight , application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, / Accepter le langage: en-us Utilisateur-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4,0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.590; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Accept-Encoding: gzip, dégonfler Proxy-Connection: Keep-Alive Host: my.domain.com

HTTP/1.1 404 Not Found Content-Length: 1635 Content- Type: text/html serveur: Microsoft-IIS/6.0 X-Powered-By: ASP.NET date: 1 juin 2009 15:38:54 GMT [balisage typique page 404 exclus]

ici sont les en-têtes Request/Response pour le bon fichier:

GET /files/file2.pdf HTTP/1.1 Accepte: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/xaml + xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/application x-ms, application/x-silverlight, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, / Accepter la langue: fr-us User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4,0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.590; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Accept-Encoding: gzip, dégonfler Proxy-Connection: Keep-Alive Host: my.domain.com

HTTP/1.1 200 OK Content-Length: 352464 Content-Type: application/pdf dernière modification: Mar Jan 2009 15:27:35 13 GMT Accept-Ranges: octets ETag: "74ccc5759375c91: 2a47" serveur: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Date: Lun, 01 Jun 2009 15:50:33 GMT

+0

Autorisations de répertoire? (Vous ne savez pas si tous les fichiers se trouvent à un endroit de votre description.) –

+0

@Michael Todd Oui, tous les fichiers se trouvent dans le même répertoire et ne sont donc pas des autorisations de niveau répertoire; Cependant, je cherche toujours à voir s'il y a une différence entre les autorisations de fichiers. Malheureusement, je n'ai encore trouvé aucune tendance. – JamesEggers

+0

C'est très étrange. Un fichier est un fichier .... IIS ne devrait pas se soucier de ce que le type est (ou quoi que ce soit d'autre à ce sujet mais des permissions), donc s'il existe, il devrait être capable de le servir. Que disent les en-têtes lors de la demande et dans la réponse? –

Répondre

0

J'ai découvert le problème étant à la configuration d'IIS. L'administrateur Sys en charge du serveur qui a rencontré ce problème a créé le répertoire virtuel avec le même nom que le sous-répertoire en cours d'indexation. Quand IIS résoudrait le chemin, les documents seraient servis à partir du répertoire virtuel au lieu du sous-répertoire comme il aurait dû l'être.

1

Pour résoudre ce problème, installez la mise à jour de sécurité cumulative la plus récente pour Internet Explorer. Pour plus d'informations techniques sur la mise à jour de sécurité cumulative la plus récente pour Internet Explorer, reportez-vous aux sections suivantes: Microsoft Web site

Questions connexes