Geckozone

Mounir Lamouri travaille sur l'implémentation de <progress>. Ce n'est pas encore fini, mais il a mis à disposition une version spéciale de Nightly (on appelle cela une version try-server), pour ceux qui veulent tester et donner des retour:

Le lien ne fonctionnera pas éternellement (les versions try sont effacées après quelques jours). Mais si vous avez du temps, allez-y. Attention c'est quand même une Nightly modifiée, hein!

Avec un peu de chance, <progress> sera dans Firefox 6.

Devant, c'est Chrome, derrière c'est le Try-Build de Mounir:

J'aime bien ces trucs, mais si c'est pas skinable, une progressbar en JS (Jquery) c'est mieux, au moins ça s’intègre parfaitement au site.
Si j'ai le temps je testerais.

Les SYN Retry ont été repoussés à Firefox 6, suite à problème de stabilité. (En d'autres termes, ils sont retirés d'Aurora et laissés dans Nightly)

Comme je n'en avais pas parlé jusqu'à présent, j'en profite.

Le problème
Dans un réseau ayant des pertes de paquets (packet loss) sur la couche de transport (TCP dans notre cas), il peut y avoir des temps importants d'établissement de la connexion.

Prenons l'exemple d'un réseau avec un taux de pertes de paquets de 0.5 % (ce qui peut paraître peu). Cela signifie qu'1 paquet sur 200 est perdu. Or, lors de chaque établissement d'une connexion, qui comporte l'échange de 5-6 messages, si le message SYN est perdu (ce qui arrive 1 fois toutes les 200 connexions, soit toutes les 30-40 sites au maximum) le partie opposée n'y répondra pas. L'émetteur attendra qu'un certain temps (un timeout) ait eu lieu avant de le renvoyer. Ce timeout est fixé par le système (qui contrôle la pile TCP/IP et donc la couche du protocole) et est de l'ordre de… 3 secondes.

Ainsi, dans un tel réseau, une fois toutes les 200 connexions, soit tous les 30-40 sites, il faut plus de 3 secondes pour ouvrir la page. Autant dire une éternité.

La solution
L'idée est d'ouvrir 2 connexions vers le site et de prendre la première qui est prête. Dans notre réseau à 0.5 % de pertes, on passe d'1 connexion sur 200 qui prend 3 s à 1 connexion sur 40'000, soit tous les 900-1600 sites sur lesquels on se rend, ce qui est plus acceptable.

C'est, en très gros, ce que fait le patch. Il reste encore quelques soucis de stabilité, rien de grave, mais le temps restant avant le passage de Firefox 5 en mode bêta imposait de s'octroyer un peu de temps supplémentaire.

Bug 623948 — Re-Implement HTTP Connection Acceleration (i.e. Syn Retry)
Bug 651635 — Security Review of SYN retry
Bug 654201 — ASSERTION: Invalid start index: 'count == 0 || start < Length()' browser_bug581076.js browser_searching.js browser_bug618502.js browser_uninstalling.js (le bug problématique)
Bug 655190 — Backout syn retry from aurora-5

Si je comprends bien, ça fait deux appels serveurs en même temps ? Ça va pas doubler du coup la charge de site demandé ?
J'avoue que la couche TCP/IP n'a jamais été une grande passion par moi.

Non, car la 2e connexion n'est pas créée immédiatement, mais après un court délai. Si la première connexion n'est pas prête après 250 ms, la deuxième est tentée. Soit rarement sur la plupart des réseaux (sauf peut-être Chine -> Hors de Chine avec le Great Firewall).

De plus la serveur devrait tenir sans problème la charge car ils sont aujourd'hui conçus pour résister à des attaques déni de service de type SYN-Flood (on l'inonde de requêtes SYN, en ignorant ses réponses, pour essayer de le faire exploser). En dessous de quelques miliers de requêtes par seconde, aucun souci.

Par contre si 2 connexions sont ouvertes, si j'ai bien compris le bug, Firefox utilisera les deux.

teoli2003 a écrit :Non, car la 2e connexion n'est pas créée immédiatement, mais après un court délai. Si la première connexion n'est pas prête après 250 ms, la deuxième est tentée. Soit rarement sur la plupart des réseaux (sauf peut-être Chine -> Hors de Chine avec le Great Firewall).

De plus la serveur devrait tenir sans problème la charge car ils sont aujourd'hui conçus pour résister à des attaques déni de service de type SYN-Flood (on l'inonde de requêtes SYN, en ignorant ses réponses, pour essayer de le faire exploser). En dessous de quelques miliers de requêtes par seconde, aucun souci.

Par contre si 2 connexions sont ouvertes, si j'ai bien compris le bug, Firefox utilisera les deux.

Merci pour ces détails. C'est juste que j'ai moi-même un serveur, et que c'est loin d'être un bête de course. (trop facile à faire tomber si on le veut)

Zefling a écrit :Merci pour ces détails. C'est juste que j'ai même un serveur, et que c'est loin d'être un bête de course. (trop facile à faire tomber si on le veut)

Si je comprend bien, c'est pas une connexion HTTP qui est établie, juste une connexion de la couche réseau, qui ne "coûte" quasiment rien (il en faut des milliers voire des dizaines de milliers pour faire tomber même un petit serveur). Apache n'est même pas au courant que la connexion a eu lieu. Sinon, tu peux être sûr que tu n'es pas le seul qui va gueuler

calimo a écrit :

Zefling a écrit :Merci pour ces détails. C'est juste que j'ai même un serveur, et que c'est loin d'être un bête de course. (trop facile à faire tomber si on le veut)

Si je comprend bien, c'est pas une connexion HTTP qui est établie, juste une connexion de la couche réseau, qui ne "coûte" quasiment rien (il en faut des milliers voire des dizaines de milliers pour faire tomber même un petit serveur). Apache n'est même pas au courant que la connexion a eu lieu. Sinon, tu peux être sûr que tu n'es pas le seul qui va gueuler

Comme dit plus, haut tout ce qui couche IP c'est pas trop mon truc, j'ai un peu séché sur le cours de réseau.

Zefling a écrit :

calimo a écrit :

Zefling a écrit :Merci pour ces détails. C'est juste que j'ai même un serveur, et que c'est loin d'être un bête de course. (trop facile à faire tomber si on le veut)

Si je comprend bien, c'est pas une connexion HTTP qui est établie, juste une connexion de la couche réseau, qui ne "coûte" quasiment rien (il en faut des milliers voire des dizaines de milliers pour faire tomber même un petit serveur). Apache n'est même pas au courant que la connexion a eu lieu. Sinon, tu peux être sûr que tu n'es pas le seul qui va gueuler

Comme dit plus, haut tout ce qui couche IP c'est pas trop mon truc, j'ai un peu séché sur le cours de réseau.

Je vois. Puisque c'est la couche de transport (TCP) qui est concernée et pas la couche de réseau (IP).

Un petit rappel: pile OSI

Couche « matérielle » : les signaux du cable Ethernet
Couche « liaison » : les messages du protocole Ethernet
Couche « réseau » : IP
Couche « transport » : TCP
Couche « session » : rien pour HTTP (ou implicite avec la durée de vie de la connexion TCP), TLS pour HTTPS
Couche « présentation » : rien (certains protocoles utilisent par exemple ASN.1, codé BER ou DER, cf SNMP par exemple), quoiqu'on pourrait ergoter s'il s'agit d'ASCII ou non (pour une pile HTTP)…
Couche « application » : HTTP

De la couche matérielle à la couche transport, le modèle OSI est peu discuté. Après les couches session, application et présentation sont des divisions plus floues, l'important étant finalement de bien garder l'idée de modèle en couche...

teoli2003 a écrit :Je vois. Puisque c'est la couche de transport (TCP) qui est concernée et pas la couche de réseau (IP).

Heu.... Perso, je m'en fous tant que ça fonctionne.

Il semblerait que les éléments ajouté pour le HTML 5 seront skinable : j'ai vu quelques bug concernant la balise <progress> qui vont dans ce sens. Je ne sais pas s'ils vont aller aussi loin que Webkit, mais ça serait cool... Le seule problème c'est que j'ai l'impression que ce n'est pas dans les specs.

Je me demande ça ira jusqu'à au input date, time, où encore des trucs chiants comme la petite flèche du <select> ou le bouton « parcourir ».

Perso, si ça pouvait aller jusqu'à l'infobulle ou les ascenseurs, ça ne me dérangerait pas le moins du monde.

Je viens de tomber une version de Nightly qui permet de tester les onglets avec plus d'animations (des animations qui font un peu penser à ce que l'on voit chez les autres) :
https://people.mozilla.com/~fyan/try-bu ... nimations/
J'ai testé, ce n'est pas super au point, ça manque de maîtrise, mais ça rend le glissement des onglets bien plus compréhensible.

Une liste des fonctionnalités en cours : Feature List updates!
Ça donne une idée de ce qui pourrait arriver dans les semaines à venir dans Firefox.

La syntaxe de CSS rect() a été restreinte.

En effet, la norme CSS, qui initialement exigeait quatre paramètres à rect(), séparée par des virgules a été modifiée (tous les navigateurs supportaient également quatre valeurs séparées par des espaces; et IE4 à IE7 ne supportaient que des espaces!).

Gecko supportait également un mélange d'espaces et de virgules pour séparer ces paramètres. Désormais ce n'est plus le case et, dès Firefox 6, la norme sera strictement suivie: quatre paramètres séparées par des virgules ou des espaces, mais pas les deux.

Bug 414638 — Disallow mixed space/comma syntax for CSS rect() value

Mounir l'a fait.

Désormais l'élément HTML5 <progress> est supporté.

À noter qu'une barre de progression ainsi définie peut être dans l'été indéterminé et donc être sélectionné par la pseudo-classe :indeterminate (la spec a été précisée récemment).
Il y a également un pseudo-élément non-standard: ::-moz-progress-bar pour définir un style. C'est un peu différent de la proposition de Webkit: https://svn.webkit.org/wiki/Styling%20Form%20Controls

Il y a encore du travail au niveau de l'accessibilité (a11y) et une régression XUL, donc si tout va bien ce sera dans Firefox 6 (le gel des fonctionnalités est dans une semaine!)

Bug 514437 — Implement content part of the progress element
Bug 633913 — Add a pseudo-class to access indeterminate <progress> elements
W3C Bug 12210 — :indeterminate should apply to progress element when in the indeterminate state
Bug 633209 — Add a pseudo-element to access <progress> bar element.