Auteur Sujet: http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https  (Lu 19725 fois)

0 Membres et 1 Invité sur ce sujet

Hugues

  • AS57199 MilkyWan
  • Expert
  • *
  • Messages: 6 096
  • Lyon & Paris
    • MilkyWan
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #48 le: 10 juin 2016 à 09:19:20 »
Et pour lafibre.info, c'est pour quand ?  :)

vivien

  • Administrateur
  • *
  • Messages: 28 803
    • Twitter LaFibre.info
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #49 le: 10 juin 2016 à 13:54:34 »
Pas pour tout de suite, le premier point bloquant est la non compatibilité de SMF 2.0.x avec PHP 7 qui bloque tout upgrade.

Le problème c'est que SMF 2.1 ne va pas sortir avant 2ans, donc j’espère qu'ils vont mettre la compatibilité PHP 7 sur SMF 2.0.x (c'est pas

N'hésitez pas à poster un petit message pour insister sur PHP 7 sur le forum de SMF : http://www.simplemachines.org/community/index.php?topic=540808.msg3871960#msg3871960

Nh3xus

  • Réseau Deux Sarres (57)
  • Client K-Net
  • *
  • Messages: 2 056
  • Sarrebourg (57)
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #50 le: 10 juin 2016 à 14:20:18 »
Citer
Le problème c'est que SMF 2.1 ne va pas sortir avant 2ans, donc j’espère qu'ils vont mettre la compatibilité PHP 7 sur SMF 2.0.x (c'est pas[...]

Pounaide by tab ?  ;D

turold

  • La fibre idéal
  • ******
  • Messages: 1 621
  • essai: mp réouverts, sauf à mes ignorés (15)
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #51 le: 10 juin 2016 à 15:00:55 »
Le problème c'est que SMF 2.1 ne va pas sortir avant 2ans
Où est le problème de planning que t'as soulevé en anglais? La sécurité de PHP 5.6 est assurée jusqu'au 31 décembre 2018.
http://php.net/supported-versions.php

Il n'y a pas de version d'Ubuntu supportée avec cette version de PHP?

Au pire, on peut installer PHP 5.6 sur 16.04, 14.04, et 12.04 via PPA
http://tecadmin.net/install-php5-on-ubuntu/#

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 5 135
  • FTTH 1Gb/s sur Paris (75)
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #52 le: 10 juin 2016 à 15:04:06 »
Il est effectivement conseillé de limiter le nombre de domaine et de connexions ouvertes.
Généralement on observer que les sites sans réseaux sociaux en http/2 utilisent 2 à 4 hébergements différents.
Wikipedia par exemple est en http/2 et a tout sur 2 nom de domaine.

A l'inverse un site vraiment mal codé : http://www.ldlc.com/
Il ouvre une centaine de connexion TCP pour afficher une page.
Ils vont devoir changer pas mal de chose pour passer en http/2.

ca n'est pas du "domain sharding" qu'ils font chez ldlc ? en HTTP 1.x, les navigateurs limitent a 6 connexions par domaine donc si on veut paralléliser plus il suffit d'utiliser plus de nom de domaines distincts, qui peuvent derriere pointer sur le meme serveur.

exemple:
- une page web avec 12 ressources (images, scripts, etc) sur nom.domain.com: le navigateur va en charger 6 au max en meme temps
- la meme page web avec 6 ressources sur n1.domain.com et 6 ressources sur n2.domain.com avec les 2 pointants sur nom.domain.com: la navigateur va charger les 12 ressources en meme temps.



cette technique est très utilisée en http 1.x mais ne rend pas forcement plus compliqué le passage en 2.0.

TroniQ89

  • @TroniQ89
  • Client Free adsl
  • *
  • Messages: 758
    • @troniq89@meld.de (Mastodon + Diaspora + Friendica)
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #53 le: 11 juin 2016 à 13:00:35 »

- Gecko (Firefox / Camino / Netscape Navigator / Mozilla Suite / SeaMonkey, Galeon)


Et Palemoon utilise Goanna (fork de Gecko) depuis Palemoon 26.
Mozilla/5.0 (X11; Linux x86_64; rv:38.9) Gecko/20100101 Goanna/2.0 Firefox/38.9 PaleMoon/26.2.2

Je le trouve très bon.

Sinon pour Servo, j'ai essayé de le compiler et je l'ai lancé avec browser.html qui est inclut dedans, c'est pas très utilisable ( trèèèèès lent )

vivien

  • Administrateur
  • *
  • Messages: 28 803
    • Twitter LaFibre.info
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #54 le: 11 juin 2016 à 14:29:53 »
Où est le problème de planning que t'as soulevé en anglais? La sécurité de PHP 5.6 est assurée jusqu'au 31 décembre 2018.
Je vais expliquer, gérer des mises à jour de sécurité sur de nombreuses années est la cause de tous ces problèmes.

Citer
Active support for PHP5.6 upstream ends Dec. 31, 2016.
Security support for PHP5.6 upstream ends Dec. 31, 2018.

Ubuntu 16.04 est supporté jusqu'en avril 2021, avec la même version de PHP. C'est qui a poussé les équipes d'Ubuntu à passer à PHP 7 qui est encore jeune : Avec PHP 5.6 il aura fallu rétro-porter les corrections de bugs depuis PHP7 pendant plus de 2 ans, ce qui demande beaucoup de travail. (Ubuntu aurais du assurer lui même le support de PHP 5.6)

C'est aussi ce support de 5 ans qui a poussé Ubuntu 16.04 a ne pas supporter http/2 avec Apache2 : La version 2.4.18 d'Apache2 est dans Ubuntu 16.04. Le support de cette version n'est pas assuré par Apache, qui a publié de nouvelle version. C'est donc les équipes d'Ubuntu qui support la version 2.4.18 pendant 5ans. Chaque bug de sécurité des version suivante d'Apache est rétro porté sur Apache 2.4.18. Faire ce travail pour http/2 aurais été compliqué car http/2 bouge beaucoup (la moitié des modifications a chaque version d'Apache) : Bref en ne supportant pas http/2 ils économisent pas mal de travail.

SMF a aussi une politique de support très étendue. SMF 2.0 sera probablement supporté encore près de 10ans. Le support de SMF 1.1 viens de s'achever.
En refusant de passer à rendre SMF 2.0 compatible PHP 7, ils ne seront plus utilisable en 2019 quand tous les hébergeur auront basculé sur PHP 7.

Ce qui bloque le passage à PHP7 est, il me semble, le fait que cela rendrait le code avec des versions très anciennes de PHP. Or SMF souhaite proposer une compatibilité avec PHP 4.1 !

On avait déjà galéré pour PHP 5.5 : SMF ne fonctionnait pas avec PHP 5.5 mais là ils avaient, tardivement fait la mise à jour du code, qui ne cassait pas la compatibilité avec PHP 4.1.
Pour vous faire rigoler, le support de PHP 4.1 a été arrêté le 12 mars 2002, il y a plus de 14ans !

J'aime bien les vieux PC et les vieux système d'exploitation, mais je trouve qu'ils ont une politique concernant le soft coté serveur qui est à revoir. Coté client, SMF 2.0 est compatible avec IE6 (pas sur LaFibre.info a cause du https), c'est discutable de garder ce support, mais coté serveur refuser de support PHP 7 pour ne pas perdre PHP 4 est incompréhensible.


Bref, pour en revenir à HTTP/2 : il faut pour avoir une version d'Apache récente, un OS avec des soft récent et donc PHP 7. Le blocage de PHP 7 me force à rester sur PHP 5 et sur des versions d'Apache qui ne supportent pas HTTP/2.

Édit, Petites précisions :

Voici les dates de fin de support officiel de PHP :
- PHP 5.3 : 14 août 2014
- PHP 5.4 : 3 septembre 2015
- PHP 5.5 : 10 juillet 2016
- PHP 5.6 : 31 décembre 2018 (durée de vie plus longue car dernière version de PHP 5)
- PHP 7.0 : 3 décembre 2018
- PHP 7.1 : fin 2019

Voici les dates de fin de support des version de PHP dans Ubuntu server :
- Ubuntu 12.04 LTS : PHP 5.3 avec backport des correctif jusqu'en avril 2017
- Ubuntu 14.04 LTS : PHP 5.5 avec backport des correctif jusqu'en avril 2019
- Ubuntu 15.10 : PHP 5.6 avec des correctif jusqu'en juillet 2016
- Ubuntu 16.04 LTS : PHP 7.0 avec backport des correctif jusqu'en avril 2021

Pour être précis sur les raisons de PHP 7 pour Ubuntu 16.04, alors que PHP 5.6 sera supporté plus longtemps que PHP 7.0, il faut préciser qu'il y a de gros changements entre PHP 5.6 et 7.0 et qu'il sera donc plus facile de faire des backport depuis PHP 7.1/PHP7.2/PHP7.3 vers PHP 7.0 plutôt que PHP 5.3

C'est la même chose pour les autres distributions avec un support de longue durée. Une exception pour Debian, qui fait des upgrade de logiciels lors de la bacul du support normal (2ans premières années) vers l'équipe de support LTS (3ème année à 5ème année).
Il faut préciser que Debian sort avec des logiciels moins récents qu'une Ubuntu, ce qui complique encore plus les choses pour le support LTS.

corrector

  • Invité
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #55 le: 12 juin 2016 à 20:24:14 »
Pas seulement Chrome et Firefox : Internet  Explorer 11 sous Win10, Microsoft Edge, Safari sous OS 10.11 et Opéra on aussi choisit de ne proposer HTTP/2 que sur SSL :
TLS, pas SSL, STP!

corrector

  • Invité
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #56 le: 13 juin 2016 à 05:54:24 »
Et sinon, vous avez compris le pb de sécurité soulevé par http/2 ? (visiblement ce n'est pas l'implèmentation dans un navigateur qui pose pb mais http/2 de manière globale)
Quelle est la raison de sécurité de suppression de MathML dans Chromium?

MathML est normalisé, a une utilité théorique mais en pratique est peu utilisé, il y a des alternatives fonctionnelles (mais qui ne sont pas normalisées ni aussi efficaces). Surtout, c'était un code pas simple qu'ils devaient considérer comme trop coûteux à vérifier.

vivien

  • Administrateur
  • *
  • Messages: 28 803
    • Twitter LaFibre.info
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #57 le: 19 juin 2016 à 21:52:57 »
J'ai déplacé les propositions de changer le moteur du forum (aujourd'hui SMF) dans un autre sujet : Passer le forum sous Discourse ?

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 727
  • île-de-France
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #58 le: 19 juin 2016 à 22:41:16 »
Quelle est la raison de sécurité de suppression de MathML dans Chromium?

MathML est normalisé, a une utilité théorique mais en pratique est peu utilisé, il y a des alternatives fonctionnelles (mais qui ne sont pas normalisées ni aussi efficaces). Surtout, c'était un code pas simple qu'ils devaient considérer comme trop coûteux à vérifier.

De mémoire, la même chose a été faîte pour Gopher sous Firefox. Un mauvais buffer overflow au niveau des URL a été trouvé ce qui a précipité la décision.

L'équipe de Chrome avait pensé à faire la même chose pour FTP à une époque, mais ça n'a pas été concrétisé.

corrector

  • Invité
http/2: Mécanisme de négociation http2 vs http1.1 dans un GET https
« Réponse #59 le: 19 juin 2016 à 22:45:24 »
J'avais même vu des discussions pour mettre à la benne le code FTP de FF! Ce qui avait engendré de fortes protestations.

 

Mobile View