Pourquoi ne peut-navigateur envoyer gzip demande?

Si le serveur web peut envoyer gzip réponse, pourquoi ne peut-navigateur envoyé gzip demande?

InformationsquelleAutor Herman | 2009-01-08
  1. 60

    Le client et le serveur se mettre d'accord sur la façon de communiquer; une partie de cette est de savoir si la communication peut être comprimé. HTTP a été conçu comme une demande/réponse modèle, et la création originale a été presque certainement envisagé d'avoir toujours de petites demandes et potentiellement de grandes réponses. La Compression n'est pas nécessaire à mettre en œuvre HTTP, il y a des serveurs et des clients qui ne le supportent pas.

    La compression HTTP est mis en œuvre par le client en disant: il peut prendre en charge la compression, et si le serveur voit cela dans la demande et il prend en charge la compression, il peut compresser la réponse. Pour compresser de la demande, le client devra disposer d'un "pré-demande" que réellement négocié que la demande serait faite comprimé OU il aurait à exiger de compression comme un codage pris en charge pour TOUTES les demandes.

    * Mise à JOUR de Février '17 *
    Cela fait 8 ans, mais comme @Phil_1984_ notes, une 3ème solution possible serait pour le client et le serveur pour négocier la compression support et ensuite l'utiliser pour les demandes suivantes. En fait, des choses comme HSTS travail exactement de cette façon, avec la mise en cache du client que le serveur s'attend à seulement parler TLS et ignorer tout chiffré des liens. HTTP a été explicitement conçu pour être apatride, mais nous avons déménagé au-delà, à ce point.

    • Si un serveur échouera si elle ne prend pas en charge la compression, alors?
    • "La Compression n'est pas requis par la spécification, il y a des serveurs et des clients qui ne le supportent pas." Le client commence par dire, "hé, je parle le français, avez-vous?" Le serveur répond, et les réponses en anglais ou en français, selon qu'il connaît le français ou pas. Français dans cet exemple est la compression. Si l'OP a demandé, le client a été en mesure de commencer à parler en français immédiatement, tous les serveurs ont à parler le français ou le système allait se briser. Le système ne permet comprimé réponses, précisément parce qu'il doit négocier et les deux systèmes d'accord.
    • Très bien expliqué. pas de compression avec petite demande (en général) sera supérieur à celui de la compression avec pré-demande de négociation.
    • Une troisième option (idéalement raté) serait pour le client/navigateur de se souvenir que le serveur Accepte la compression et puis après les données compressées plus tard dans la connexion si elle en a besoin. La validation de grandes charges n'est jamais la première chose qu'un navigateur n'lors de la connexion à un serveur de toute façon.
    • Il va à l'encontre de la apatrides conception de HTTP, mais à ce point, compte tenu de toutes les autres choses que de les ignorer cette partie, je pense que vous avez absolument raison de l'ajout de cette option. Je vais modifier la réponse de la noter.
    • Il a été plus d'un à se plaindre au navigateur devs ou des rédacteurs de devis, je ne sais pas qui blâmer, exactement. Les navigateurs ne la complexe dynamique des choses comme souvenir de HSTS en-têtes par domaine (par exemple), mais ils ne me souviens pas acceptable de transfert de fichiers. D'y penser plus, je pense que quand un client commence à se souvenir de choses à propos d'un domaine, vous obtenez dans le domaine de la mise en cache et pour combien de temps. La spécification des designers n'a jamais pensé à avoir un cache acceptable de codage de transfert d'en-tête.
    • Je pense que le contexte historique est utile; il peut être facile d'oublier à quel point nous avons parcouru. En 1989, lors de HTTP a été conçu comme apatrides, les 486 cours d'exécution à un énorme 20MHz avait été annoncé mais n'a pas vraiment d'être disponible jusqu'au printemps suivant. L'internet n'avait pas vraiment évolué à partir d'un espace universitaire de la connexion des universités et des gouvernements. Apatrides fait beaucoup de sens à l'époque. En tant qu'agents (les navigateurs) a obtenu beaucoup plus complexe dans les 28 dernières années, il est logique d'ajouter plus dynamique, notamment pour mettre en œuvre des cas d'utilisation spécifiques qui est l'endroit où HSTS vient de.

    InformationsquelleAutor Peter Oehlert
  2. 27

    Un client ne peut pas savoir à l'avance que le serveur serait de comprendre un format gzip demande, mais le serveur peut savoir ce que le client accepte une.

    • Pas vrai. Encodage de contenu est interdit d'en-tête pour le client à l'offre. Le RFC dit: "Si le contenu de codage d'une entité dans un message de demande n'est pas acceptable à l'origine de serveur, le serveur DOIT répondre avec un code d'état de 415 (Unsupported Media Type)." - par Nick Johnson
    • Ce que vous dites, c'est un peu différent de ce que j'ai été conduite à l'. Vous pouvez essayer pour envoyer un gzippé demande comme vous le suggérez, mais il n'y a aucun moyen de savoir à l'avance que le serveur va accepter (sans parler au serveur). Cela dit, votre point est bien faite: si vous essayez d'envoyer un gzippé demande, vous pouvez trouver le serveur peut le supporter.
    • Il y a beaucoup d'endroits où vous savez à l'avance que le serveur prend en charge cette. Par exemple et application mobile à parler à l'arrière-plan.
    • S'il existe une liste de serveurs qui supportent un format gzip demande?
    • y sont aucun les navigateurs qui la soutiennent?
    • la compression fait principalement référence à des données de formulaire, dans ce cas, le client toujours connaître le serveur veut compressé car le serveur, à condition que le formulaire de demande de cette façon.

    InformationsquelleAutor Paul Dixon
  3. 7

    Il pourrait, si on peut garantir que le serveur de l'accepter. Cela pourrait signifier à l'aide d'une des OPTIONS de demande.

    Il y a beaucoup de choses que les navigateurs web pourrait le faire (par exemple, le pipelining) qu'ils ne le font pas. Navigateur Web développeurs doivent prendre en compte la compatibilité des conséquences d'un changement.

    Dans un environnement hétérogène, il y a beaucoup de différents serveurs web et des configurations. Faire un changement à la façon dont un client pourrait briser certains d'entre eux.

    Peut-être seulement 1% des serveurs pourraient accepter gzippé demandes, mais peut-être certains de ceux de la publicité qu'ils font, mais ne peut pas correctement l'accepter - les utilisateurs pourraient donc être refusée dès le téléchargement de fichiers sur ces sites.

    Historiquement il y a eu beaucoup de débris de client /serveur implémentations - pour une longue période, au format gzip réponses ont été brisées dans les principaux navigateurs web (heureusement ceux-ci sont maintenant pour la plupart disparu).

    Donc, si vous voulez retrouver avec des listes noires des user-agents ou des serveurs (ou les noms de domaine) où ces options sont automatiquement mis à l'arrêt, qui est méchant.

    InformationsquelleAutor MarkR
  4. 3

    Parce qu'il ne sait pas que le serveur peut accepter. Une transaction HTTP a une seule requête envoyée par le client suivie d'une réponse. Une des choses que le client envoie est ce que le codage/de compression, il peut prendre en charge. Le serveur peut ensuite décider de la façon de compresser la réponse. Le client n'a pas ce luxe.

    • Eh bien, si le serveur peut déterminer si le navigateur prend en charge ou pas, il y a PEUT être une mise en œuvre qui navigateur essaie de trouver si le serveur peut comprendre le g-zippé contenu ou non; si les développeurs à travailler sur ce point.
    • Le serveur détermine que le navigateur prend en charge gzip, car le navigateur dit par l'intermédiaire d'une Accept-Encoding. Vous avez besoin d'un autre moyen de le navigateur de savoir a priori ce que le serveur de capacités. Cela est en dehors de ce que HTTP/1.1 vous donne.
    • Tu veux dire (par exemple) à l'aide du navigateur de mémoire pour se souvenir d'un des serveurs Accept-Encoding réponse?
    InformationsquelleAutor Yuliy
  5. 2

    Si vous écrivez une application web, je suis en supposant que vous êtes en contrôle de ce qui est envoyé au client et ce qui est renvoyé par le client.

    Il serait assez facile d'écrire un gzip implémentation en javascript, qui comprime le post de données envoyées vers le serveur. Le serveur pourrait avoir un filtre (j2ee terme), qui ne connaît client de l'envoi de données compressées, ce filtre permet de décompresser les données et les transmet ensuite les données de la servlet (ou classes d'action de Struts) que lire les données comme normal par exemple la requête.getParameter(...).

    Cela semble parfaitement logique et faisable si vous êtes dans le contrôle. Comme d'autres postes de mentionner, on ne pouvait pas compter sur le navigateur pour le faire automatiquement, mais puisque vous êtes en train de rédiger les pages web, vous pouvez obtenir le navigateur pour faire la compression que vous êtes après (avec un peu de travail).

    Andy.

    InformationsquelleAutor
  6. 0

    HTTP est conçu de cette façon:

    • Le client déclare sa demande en texte brut (y compris si peut comprendre comprimé réponses)
    • Les réponses du serveur avec le propper encodage (compressé ou non)

    MAIS DANS CE modèle, le client ne peut pas envoyer un comprimé demandes, car il ne sait pas si le serveur se comprendre à l'avance.

    InformationsquelleAutor Jairo Andres Velasco Romero