Je le note parce que je l'oublie à chaque fois :
- Un paramètre d'une requête est ce que le client envoie au serveur.
- Un attribut d'une requête est ce que le serveur ajoute lui-même à la requête, le client n'intervient pas dans l'opération.
Je dois écrire un µ-service en Rust et j'ai cherché pas mal de serveurs web permettant de le faire. Évidemment, la première chose que les moteurs de recherche nous remontent c'est Hyper. Pour faire simple, Hyper est une serveur HTTP 1/2 qui s'appuie sur le pool de threads asychrone Tokio.
Problème, Hyper reste assez bas niveau. Je recherchais donc quelque chose aux performances équivalentes mais bien plus simple d'utilisation et je suis tombée sur Actix qui à l'air de faire le café. Je regrette uniquement la reprise du annotation-driven-bullshit via les macros déclaratives mais en dehors de cela, tout va bien.
Exemple de hello world en Actix / Rust :
use actix_web::{get, web, App, HttpServer, Responder};
#[get("/")]
async fn index() -> impl Responder {
"Hello, World!"
}
#[get("/{name}")]
async fn hello(name: web::Path<String>) -> impl Responder {
format!("Hello {}!", &name)
}
#[actix_web::main]
async fn main() -> std::io::Result<()> {
HttpServer::new(|| App::new().service(index).service(hello))
.bind(("127.0.0.1", 8080))?
.run()
.await
}
L'ordre de déclaration est le suivant :
http://www.example.com?foo=bar&bla=valuebla#myAnchor
Ce qui explique pourquoi nous ne parvenions pas à mélanger ancres et paramètres d'URL chez mon client. Nos prestataires écrivant http://www.example.com/#hashme?foo=bar&bla=valuebla
ce qui syntaxiquement est faux.
Quand je pense qu'ils sont bloqués sur ça depuis octobre/nombre et que 3 minutes (à peine) de recherche m'ont suffit à trouver la réponse... J'ai de la peine pour eux.
Quelques benchmarks sur des serveurs http. Je partage surtout pour les lignes de commande de siege
(l'utilitaire de benchmark utilisé).
En ce moment je regarde rapidoid et undertow, je recherche des serveurs web ultra-rapides et ultra-légers pour faire de l'embarqué sur du GraalVM natif (et peut-être remplacer Sparkjava qui ne reçoit plus de mises à jour).
J'ai enfin trouvé ! Merci à la team PeerTube qui affiche clairement ce qu'il se passe dans la console du navigateur :) #ZestesLesMeilleurs
En résumé, le protocole HTTP permet d'envoyer du contenu par morceaux : les Partial Contents dont le code de transfert est 206. Ce faisant, il est possible de streamer un flux vidéo en chunks où ces blocs téléchargés un à un sont en fait des plages d'octets bruts à rassembler dans le bon ordre côté client.
Donc pour mettre en place une telle solution il faut :
1) Un serveur qui sache envoyer du contenu par morceaux (et dans le bon ordre ou alors fournissant à ses clients le moyen de remettre les partials dans le bon ordre).
2) Un client qui sache récupérer ce contenu par parties puis le rassembler.
Évidemment une fois que le contenu fût intégralement téléchargé, il devient un gros fichier placé dans le cache du navigateur sauf si l'on décide de l'enregistrer dans le local storage (il faut alors penser à lever la limite des 5 Mo s'il s'agit d'un très gros fichier).
Je vais regarder pour me bidouiller quelque chose courant de la semaine prochaine (parce que ponçage demain et peinture dimanche) mais je suis contente.
Déterminer la charge soutenable par votre service REST en déclarant les requêtes via une syntaxe Yaml proche de celle d'Ansible.
Via Doo.
Les hearders à intégrer à vos rôles Ansible/Nginx et pourquoi.
En voulant rendre accessible une application Web de l'extérieur en passant par un reverse proxy apache, je me suis aperçu que les liens vers les fichiers CSS [...] étaient en dur.
Bon, comment réécrire dynamiquement les URL absolues, c'est-à-dire de la forme http(s)://host:port/path
à la place de /path
, dans vos pages (#MauvaisePratique) avec Apache.
Effectivement je n'y avais pas pensé : les réponses des requêtes JSON qu'effectue une PWA peuvent être mises en cache par le navigateur lui-même. Ce faisant, la seconde fois qu'une requête est jouée, la réponse de celle-ci peut ne pas avoir de résultat à jour.
Ceci dit, lorsque le serveur ajoute en entête de message qu'il répondra du "application/json", il me semble que le navigateur téléchargera toujours ce contenu à l'image de ce qu'il fait pour une page HTML (sauf si un cache contrôle est défini côté serveur avec une durée supérieure à zéro).
Le mieux étant de faire comme le dit Timo, à savoir ajouter côté serveur l'option
Cache-Control: max-age=0
Editer ou créer le fichier /etc/apt/apt.conf et ajouter les lignes suivantes en les adaptant :
Acquire::http::proxy "http://myname:mypass@localhost:5865/";
Acquire::ftp::proxy "ftp://myname:mypass@localhost:5865/";
Pour Roudoudoutte.
Comment gérer les cookies avec la nouvelle réglementation par Korben.
Coudifié
La pop-up toute moisie qui vous annonce que le HTTP utilise des cookies... Ici Nikopik dresse le bilan de ce qu'il se passe.
Une solution géniale ! J'adore.
Google est en train d'effacer petit à petit sa barre d'adresse. En clair les gens qui utilisent Chrome ne peut plus accéder à un site en tapant directement l'adresse du site dans la barre d'url, non à la place cela va lancer une recherche sur Google qui obtient par la même occasion un contrôle complet sur :
- ce que vous faites ;
- combien de temps vous y serez ;
- combien de fois vous vous y rendez.
Mais le pire n'est pas là, le pire c'est que si Google décide de déréférencer un site (à cause d'un gouvernement par exemple), vous ne pourrez plus y accéder même en saisissant l'url dans la barre. Google N'EST PAS VOTRE AMI ! Quand est-ce que les gens comprendront que Firefox et la fondation Mozilla leur veulent du bien eux.
Les liens de mistu parlent d'eux-même pour le reste.