2009-07-08 12 views

Respuesta

6

Es necesario crear un tipo MIME para esa extensión en IIS:

para definir un tipo MIME para una extensión específica, siga estos pasos:

  1. Abra la consola de administración de Microsoft IIS (MMC) , haga clic con el botón derecho en el nombre de la computadora local y luego haga clic en Propiedades.
  2. Haga clic en Cabeceras HTTP.
  3. Haga clic en Tipos MIME.
  4. Haga clic en Nuevo.
  5. En el cuadro Extensión, escriba la extensión de nombre de archivo que desea (por ejemplo, .axed)
  6. En el cuadro Tipo MIME, escriba application/octet-stream.
  7. Aplicar la nueva configuración. Tenga en cuenta que debe reiniciar el servicio de publicación World Wide Web o esperar a que el proceso de trabajo se recicle para que los cambios surtan efecto. En este ejemplo, IIS ahora sirve archivos con la extensión .axed.
+0

No, no es eso. Tengo la sensación de que el servidor está eliminando los parámetros querystring de los archivos .axd y .asmx ya que mis servicios web tampoco funcionan. ¿Alguien es consciente de algo que evitaría esto (no es que no falta el verbo de la extensión, ya que genera un error diferente) – januszstabik

+0

¿Qué versión de IIS está ejecutando? – Alex

+0

¿Estoy pensando que podría tener un problema de permisos? ¿Puedes ver algo más en ese servidor? .aspx? ¿Cualquier cosa? – Alex

2

Tuvimos el error 500 (no es 404, pero quién sabe) en nuestro servidor de producción hace algún tiempo. No se pudieron cargar recursos de scripts.

El problema estaba en la diferencia horaria entre nuestros servidores de desarrollo y producción. Fue -7 horas. .NET lanzó una excepción porque intentó usar un "tiempo en el futuro" de un ensamblado con recursos de scripts incrustados.

Disminuyendo la carpeta {website}/bin/ (en realidad los ensamblajes 'en ella) la creación de la fecha por día resolvió el problema.

+0

Gracias por la sugerencia. Me gustaría probar esto. ¿Qué herramienta usaste para cambiar las marcas de tiempo? – itslittlejohn

+0

Este fue de hecho el problema para nosotros, y obtuvimos 404s. Usé el cambiador de fechas de archivos de Nirsoft. – itslittlejohn

0

¿Puede hacer una solicitud "incorrecta" que falla y luego verificar el sistema del servidor y los registros de eventos de la aplicación?

Hay varios problemas alrededor de axd que pueden causar 404 o 500 (como el problema del "tiempo en el futuro" mencionado por Alex), pero dejan una huella en el registro de eventos.

Eche un vistazo y publique cualquier entrada de registro que mencione axds.

3

Usted puede comprobar lo siguiente:

  1. Comprobar en la consola de administración de IIS que se permite la extensión .axd (la extensión controlador HTTP por defecto).
  2. También compruebe si la casilla de verificación "Verificar si el archivo existe" es desmarcada. Esta pantalla aparece después de hacer clic en el botón "Editar" después de seleccionar la extensión axd.
  3. Compruebe si el controlador HTTP está registrado correctamente en web.config. También debería estar en la sección de configuración correcta según la versión de IIS. Para el modo IIS6 e IIS7 Classic, debe estar en <system.web><httpHandlers>. Para el modo integrado IIS7, debe registrarse en <system.webServer><handlers>.
15

si estás en IIS7 asegúrese de agregar el controlador a la sección <system.webServer><handlers>:

<add name="MyName" path="MyName.axd" verb="*" type="NameSpace.Class, Assembly" /> 
4

confirman que en Request Filtering que o bien tienen * .axd como una extensión animales, o * tienen Allow unlisted file name extensions marcado en Editar configuración de filtrado de solicitudes

Se puede lograr el mismo efecto con la siguiente sección web.config:

<system.webServer> 
    <security> 
     <requestFiltering> 
      <fileExtensions> 
       <add fileExtension=".axd" allowed="true" /> 
      </fileExtensions> 
     </requestFiltering> 
    </security> 
</system.webServer> 
+0

Yo quería hacer lo contrario, así que esto fue perfecto (obviamente, acabo de usar 'falso' en lugar de' verdadero'). – Fenton

7

En mi caso, estaba transfiriendo proyectos de .NET 2.0 utilizando la conversión automática. Converter agregó la sección <system.webServer> y todos los controladores y módulos que están en el <system.web>. Sin embargo, para cada controlador agregó el siguiente atributo: preCondition = "integratedMode, runtimeVersionv2.0" Una vez que eliminé el atributo, los 404 se detuvieron y el manejador comenzó a funcionar.

+0

¡Gracias por salvarme una cantidad de tiempo desconocida, pero probablemente significativa! – bentayloruk

0

I añade un atributo runAllManagedModulesForAllRequests = "true" en módulos .. nodo de la sección system.webServer, los 404s detuvo y manejador comenzó a trabajar.

0

Si esto ayuda a alguien, tuve el mismo problema, pocos de nosotros pasamos 2 días. En 3 servidores, todo funcionó bien y también en el desarrollo, pero en este servidor 404 no se detuvo. La solución, cambié poold de integrado a clásico y funcionó

Cuestiones relacionadas