Chrome dice " Recurso interpretado como script, pero transferido con el tipo MIME text / plain.", lo que da?

Esto no tiene nada que ver con jQuery o cualquier peculiaridad del código script del lado del cliente. Es un problema del lado del servidor : El servidor (aplicación del lado) no está enviando el HTTP esperadoContent-Type campo de encabezado valor para el recurso script del lado del cliente. Esto sucede si el servidor Web está insuficientemente configurado, mal configurado, o una aplicación del lado del servidor (por ejemplo, PHP) está generando el recurso de script del lado del cliente.

Tipos de medios MIME adecuados para ECMAScript las implementaciones como JavaScript incluyen:

• text/javascript (registrado como obsoleto , no obsoleto; pero aún así válido , y soportado mejor )
• text/ecmascript (registrado como obsoleto , no obsoleto; pero aún así válido )
• application/javascript
• application/ecmascript

Lo hacen no incluyen application/x-javascript, ya que los tipos de medios MIME enumerados anteriormente son los registrados en el árbol de estándares por ahora (por lo que no hay necesidad, y hay debería ser no querer, para utilizar los experimentales más). Cf. RFC 4329, "Scripting Media Types" (2005 CE) y mi Caso de prueba : Soporte para Scripting Media Types.

Una solución es configurar el servidor si es posible, como ya se recomendó. Para Apache, esto puede ser tan simple como agregar la directiva

AddType text/javascript .js

(vea la documentación del servidor HTTP Apache para más detalles).

Pero si el recurso script del lado cliente es generado por un servidor aplicación, como PHP, entonces es necesario establecer el valor del campo de encabezado Content-Type explícitamente, ya que el valor predeterminado es probablemente text/html:

<?php
  header('Content-Type: text/javascript; charset=UTF-8');
  // ...
?>

(Esa y otras instrucciones similares deben venir antes de cualquier otra salida – ver el manual de PHP –, de lo contrario se considera que el cuerpo del mensaje HTTP ya ha comenzado y es demasiado tarde para enviar más campos de encabezado.)

La generación del lado del servidor puede ocurrir fácilmente a un recurso de script del lado del cliente, incluso si tiene plain .archivos js en el servidor, si los comentarios se eliminan a medida que se sirven, si todos se empaquetan en una respuesta grande (para reducir el número de solicitudes, lo que puede ser más eficiente), o si la aplicación del lado del servidor los minimiza de cualquier otra manera.

Para servidores de aplicaciones Java como Weblogic

1) Asegúrese de que su weblogic.el archivo xml está libre de errores

Como este:

    <?xml version = '1.0' encoding = 'windows-1252'?>
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"
                  xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
    <container-descriptor>
        <prefer-web-inf-classes>true</prefer-web-inf-classes>
    </container-descriptor>
    <context-root>MyWebApp</context-root>
</weblogic-web-app>

2) Agregue un tipo mime para javascript a su web.archivo xml :

    ...
        </servlet-mapping>

        <mime-mapping>    
            <extension>js</extension>        
            <mime-type>application/javascript</mime-type>        
        </mime-mapping>

        <welcome-file-list>
    ...

Esto también funcionará para otros contenedores Java-Tomcat, etc. application/javascript es actualmente el único tipo mime válido; otros como text/javascript han sido obsoletos.

3) Es posible que deba limpiar la caché de su navegador o presionar CTRL-F5

Si está generando su javascript con un archivo php, agregue esto como el comienzo de su archivo:

<?php Header("Content-Type: application/x-javascript; charset=UTF-8"); ?>

Tuve este problema y descubrí cómo solucionarlo.

Sucede cuando el archivo de estilo (CSS) está en una codificación diferente del archivo PHP que hace referencia al .css file

Por ejemplo, usando jQuery.js en Unix codificando y usando index.php en UTF-8 causará este problema, por lo que debe hacer que ambos sean UTF-8 o cualquier otra codificación siempre y cuando sea la misma.

En el httpd de apache.conf, solo tiene que añadir una línea:

AddType application/x-javascript .js

Era un problema.. pero esto me ayudó a resolver mi problema. A veces, incluso las cosas más fáciles son difíciles de entender...

En lugar de usar

/js/main.css en mi script-tag

He utilizado js/main.css

SÍ , realmente hizo una diferencia. Estoy sentado en WAMP / Windows y no tenía un vhost pero solo usé localhost/<project>

Si hago referencia a /js/main.css a continuación hago referencia a localhost/css/main.css y no a localhost/<project>/css/main.css

Cuando lo piensas, es bastante obvio pero si alguien tropieza con esto, pensé que compartiría esta respuesta.

Recibí este mensaje de depuración por una razón más tonta que las otras respuestas aquí: Este es el mensaje de error recibido cuando no duermes lo suficiente y haces referencia a un archivo js usando la sintaxis de un archivo css. Como en,

<link rel='stylesheet' type='text/css' href='clearly_javascript.js'/>

En lugar de

<script src='clearly_javascript.js'></script>

Pensé en poner esto aquí porque este es el primer post que aparece al buscar el mensaje de error.

Compruebe que sus archivos js realmente existen en el servidor. Tuve este problema y descubrí que los archivos js no se habían subido al servidor y el servidor estaba devolviendo la página html en su lugar, que era el documento predeterminado configurado en el servidor (por ejemplo, predeterminado.html)

Si estás trabajando en Joomla! y obtener este molesto error al tratar de incluir un archivo JavaScript (.js), entonces la siguiente solución es para usted.

El problema más probable es que usted está tratando de incluir un .js archivo que no está ahí, o simplemente extravió ese archivo .js, y cuando Joomla! no encuentra un recurso, entonces en lugar del mensaje 404 genérico, devuelve un mensaje 404 completo con una página web completa y html, etc.

El navegador web es interpretándolo como .js mientras que es solo una página web que dice que el archivo requerido no se encontró.

Esto puede funcionar para joomla2.5joomla3.0joomla3.1joomla3.2joomla3.3joomla

Para mí, solo sucedió en algunas páginas porque usé window.location en lugar de $location.url(...); Esto solucionó mi problema. Tomó un tiempo para averiguar :)

Tuve este problema mientras usaba un marco web y lo solucioné moviendo los archivos javascript relevantes a la carpeta javascript designada (por el marco).

Una cosa común cuando esto sucede es si simplemente ha olvidado incluir el type en sus llamadas de script. Tendrás que configurarlo explícitamente, tal como está-de acuerdo con W3 - requerido :

type (content-type): Este atributo especifica el lenguaje de scripting del contenido del elemento y anula el lenguaje de scripting predeterminado. El lenguaje de scripting se especifica como un tipo de contenido (por ejemplo, "text/javascript"). Los autores deben proporcionar un valor para este atributo. Hay sin valor predeterminado para este atributo.

Todavía parece que los navegadores tienen un valor predeterminado de plain/text.

Ejemplo:

<script type="text/javascript" src="http://maps.googleapis.com/maps/api/js?sensor=false&language=en"></script>

También podría establecer un valor predeterminado para esa extensión de archivo en su configuración de Apache:

<IfModule mod_mime.c>
    AddType text/javascript .js
</IfModule>

Si su IIS asegúrese De Que debajo de su common HTTP Features tiene Static Content activado

Tuve el mismo error y finalmente (en mi caso particular) encontré un problema en el descriptor de implementación (web.xml)

El problema:

<servlet-mapping>
    <servlet-name>SessionController</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>
...
<welcome-file-list>
    <welcome-file>/</welcome-file>
</welcome-file-list>

La solución:

<servlet-mapping>
    <servlet-name>SessionController</servlet-name>
    <url-pattern>/SessionController</url-pattern>
</servlet-mapping>
...
<welcome-file-list>
    <welcome-file>desktop.jsp</welcome-file>
</welcome-file-list>

Si está utilizando Spring MVC, puede agregar la siguiente etiqueta mvn para excluir el archivo de recursos de Spring Dispatch Servlet

<mvc:resources mapping="/js/*.js" location="/js/"/>
<mvc:resources mapping="/css/*.css" location="/css/"/>
<mvc:resources mapping="/images/*.*" location="/images/"/>

En mi caso, el servidor estaba enviando el Content-Type correcto pero con un Content-Encoding incorrecto. Asegúrese de que solo establece Content-Encoding: gzip para recursos comprimidos con gzip. Además, después de arreglar los encabezados en el servidor (en mi caso, Google Cloud Storage), tuve que esperar unos minutos para reflejar correctamente los cambios debido al almacenamiento en caché.

Estaba teniendo el mismo problema al intentar cambiar imágenes de fondo en una matriz a través de javascript (jQuery en este caso).

De todos modos.

En lugar de esto:

m.setStyle('background-image','url(/templates/site/images/style5/'+backgs[i]+')')

Haz esto:

eval("m.setStyle('background-image','url(/templates/site/images/style5/'+backgs[i]+')')");

Chrome javascript se atornilla cuando se intenta analizar una variable dentro de un elemento estructurado con ' . En mi caso, se detuvo justo antes de que se insertara la matriz de imágenes. En lugar de analizar la url de la imagen + nombre de la imagen (dentro de la matriz), estaba analizando solo la imagen URL.

Probablemente necesite buscar dentro del código y ver dónde sucede. FF, IE y todos los demás no tienen este problema.

La respuesta publicada aquí por simon-sarris me ayudó.

Esto me ayudó a resolver mi problema.

El instalador de Visual Studio debe haber añadido una línea errante al registro.

Abre regedit y echa un vistazo a esta clave de registro:

¿Ves esa llave? La clave de Tipo de Contenido? cambie su valor de text / plain a text / javascript.

Finalmente chrome puede respirar tranquilo de nuevo.

Debo señalar que ni Content Type ni PercievedType están por defecto en Windows 7, por lo que probablemente podría eliminarlos de forma segura, pero lo mínimo que necesita hacer es editar.

De todos modos espero que esto lo arregle para usted también!

No olvide reiniciar el sistema después de los cambios.