Suport technique et veille technologique
Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Juin 2022 -
Le protocole HTTP, qui est à la base du Web, n'est pas forcément de bout
en bout, entre client et serveur. Il y a souvent passage par un
relais et ce relais a
parfois des choses à signaler au client HTTP, notamment en cas
d'erreur. Ce RFC
spécifie le champ d'en-tête Proxy-Status
pour
cela.
La norme HTTP, le RFC 9110 décrit
ces relais, ces intermédiaires, dans sa section 3.7. On en trouve
fréquemment sur le Web. Il y a depuis longtemps des codes d'erreur
pour eux, comme 502 si le serveur d'origine répond mal et 504 pour
les cas où il ne répond pas du tout. Mais ce n'est pas forcément
assez précis, d'où le nouveau champ dans l'en-tête (ou dans le
pied). Il utilise la syntaxe des champs structurés du RFC 8941. Voici un exemple :
Proxy-Status: proxy.example.net; error="http_protocol_error"; details="Malformed response header: space before colon",
"Example CDN"
Cet exemple se lit ainsi : le premier (en partant du serveur
d'origine) s'identifie comme
proxy.example.net
et il signale que le serveur d'origine n'avait pas bien lu le RFC 9112. Puis la réponse est passée par un autre
intermédiaire, qui s'identifie comme
"Example
CDN"
(l'identificateur n'est pas forcément un
nom de domaine), et n'a rien de particulier à
raconter. Le champ
Proxy-Status
est désormais
dans
le registres des champs d'en-tête (ou de pied).
Vous avez vu dans l'exemple ci-dessus le paramètre
error
. Il peut s'utiliser, par exemple, avec le
code de retour 504 :
HTTP/1.1 504 Gateway Timeout
Proxy-Status: foobar.example.net; error=connection_timeout
Ici, le relais
foobar.example.net
n'a eu aucune
réponse du serveur d'origine (ou, plus rigoureusement, du serveur
qu'il essayait de contacter, qui peut être un autre
intermédiaire).
Mais il existe d'autres
paramètres possibles, comme :
next-hop
: nom ou adresse du serveur
contacté, par exemple Proxy-Status: cdn.example.org;
next-hop=backend.example.org:8001
.
next-protocol
: protocole
(ALPN,
RFC 7301) utilisé avec
le serveur, par exemple Proxy-Status:
"proxy.example.org"; next-protocol=h2
pour du HTTP/2
(RFC 9113).
received-status
: le code de retour du
serveur, comme dans Proxy-Status: ExampleCDN;
received-status=200
, pour un cas où tout s'est bien
passé.
Et on peut définir de nouveaux paramètres par la procédure d'examen
par un expert (RFC 8126).
Le paramètre error
prend comme valeur un
type d'erreur. Il en existe
plusieurs, chacun avec un code de retour recommandé dont (je
ne les indique pas tous, ils sont très nombreux !) :
dns_timeout
(pour le code de retour
504) et dns_error
(code 502) : c'est la faute du
DNS. Le second type permet en outre
d'indiquer le paramètre rcode
(code de retour
DNS, comme NXDOMAIN
) et le paramètre
info-code
, le code étendu du RFC 8914.
connection_timeout
ou connection_refused
.
destination_ip_prohibited
: le
pare-feu ne veut pas.
tls_protocol_error
: là, c'est
TLS qui ne veut pas.
tls_certificate_error
:
certificat du serveur problématique, par
exemple expiré.
http_protocol_error
: la réponse du
serveur n'était pas du bon HTTP.
proxy_internal_error
: le relais a un
problème interne.
Là aussi, on peut enregistrer de nouveaux types avec la procédure
d'examen par un expert du RFC 8126.
La section 4 du RFC détaille les questions de sécurité. Comme
toute information, Proxy-Status
peut aider un
attaquant, par exemple en lui donnant des idées sur comment joindre
directement un intermédiaire. Pour cette raison, les logiciels
doivent fournir un moyen de contrôler l'ajout (ou pas) de
Proxy-Status
, qu'on peut aussi n'inclure que
dans certains cas. Notez aussi qu'un intermédiaire peut mentir (ou
se tromper) et que le Proxy-Status
ne vaut donc
que ce que vaut l'intermédiaire.
Je n'ai pas de liste des logiciels qui mettent en œuvre ce champ Proxy-Status
.
RFC 9562: Universally Unique IDentifiers (UUIDs)
- 12 mai -
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec (...)
RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- 9 mai -
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il (...)
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
- 29 avril -
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher (...)
RFC 9567: DNS Error Reporting
- 27 avril -
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et (...)
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 8 avril -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)