Est HTTP Content-Type d'en-tête de toujours nécessaire?

Cette question concerne le comportement du navigateur ainsi que la spécification du protocole de la liaison, de l'importation, y compris la ou ajaxing CSS, JS, images et autres fichiers à partir de pages web, fichiers js ou css fichiers.

Lors de tests sur des fichiers statiques et comprimé contenu de la livraison, j'ai constaté que peu de navigateurs créer de problème si vous vous éloignez de conventions. Comme: IE6 crée de problème si vous n'envoyez pas Content-Disposition: inline; - tête pour tous les CSS, JS etc fichiers, et qui n'est pas très vieille version de safari ne traite pas correctement le format des fichiers CSS si vous utilisez l'extension de fichier .gz comme dans main-styles.css.gz.

Je voudrais vous interroger sur le comportement des navigateurs sur Content-Type en-tête de réponse. Depuis <link>, <script> et <img> déjà spécifier le type de contenu, cet en-tête peut être ignorées, ou de faire certains navigateurs besoin pour une raison quelconque?

OriginalL'auteur Hamid Sarfraz | 2013-12-05

  1. 9

    En bref, non, il n'est pas nécessaire. Mais il est recommandé.
    La plupart des navigateurs, que je sache, permettra de traiter <link>, <script>, et <img> correctement si ils ne sont pas envoyés avec les en-têtes, mais il n'y a pas de vraie bonne raison de ne pas envoyer les en-têtes. En gros, sans Content-Type en-têtes, le navigateur est à gauche pour essayer de le deviner sur la base du contenu.

    De la RFC2616:

    Content-Type spécifie le type de support de données sous-jacentes.

    Encodage de contenu peut être utilisé pour indiquer un contenu supplémentaire

    les codages appliqué aux données, généralement dans le but de données

    compression, qui sont une propriété de la ressource demandée. Il n'y a

    pas de codage par défaut.

    Tout HTTP/1.1 message contenant une entité DOIT inclure un

    Contenu Type de champ d'en-tête de la définition du type de support du corps. Si

    et seulement si le type de média n'est pas donnée par un champ Content-Type, l'

    le bénéficiaire PEUT tenter de deviner le type de média via l'inspection de ses

    le contenu et/ou le nom de l'extension(s) de l'URI utilisée pour identifier le

    de la ressource. Si le type de média reste inconnu, le destinataire DOIT

    traiter comme de type "application/octet-stream".

    Concernant le mot-clé DOIT, spécifié dans RFC2119:

    DEVRAIT: Ce mot, ou l'adjectif "RECOMMANDÉ", signifie qu'il n'y

    il peut exister des raisons valides dans des circonstances particulières d'ignorer un

    article en particulier, mais toutes les implications doivent être compris et

    soigneusement pesé avant de choisir un cours différent.

    OriginalL'auteur arcyqwerty

  2. 1

    J'ai rencontré un problème en java où j'ai essayé de poster quelques données par l'intermédiaire de la bibliothèque chrriis.dj.nativeswing.swtimpl.des composants.JWebBrowser, qui, en gros, affiche un internet explorer à l'intérieur d'un programme java. Mais le simple script php sur le back-end ne serait pas analyser mon post. (Utilisé WebBrowserNavigationParameters pour définir publier des données lors de la navigation vers une certaine page), j'ai finalement trouvé que le Contenu de l'en-tête de Type a dû être mis pour php pour bien coller les post-données. (Ce n'était pas définie par défaut.) Le paramètre Content-Type: application/x-www-form-urlencoded et tout a bien fonctionné. Alors, je pense que le réglage de Type de Contenu doit toujours être fait lors de la Publication de données en php.

    OriginalL'auteur runholen

  3. 1

    Il est nécessaire pour la compatibilité descendante.

    Par exemple: Internet Explorer 10 besoins Content-Type:image/svg+xml afin de rendre n'importe quel svg fichier

    IE10, IE9 et probablement d'autres navigateurs ont toujours besoin de la Content-Type en-tête.

    OriginalL'auteur ncomputers