questions sur le protocole [HTTP] - Programmation
Marsh Posté le 10-02-2002 à 14:10:34
ben ca définit les types mime gérés par le navigateur client.
C'est envoyé par le navigateur à chaque requête.
je n'es sais pas beaucoup plus et je n'ai jamais rencontré de cas où le serveur HTTP se servait de cette info ...
Marsh Posté le 10-02-2002 à 14:18:50
pour plus d'infos sur ce header : http://www.salemioche.com/http_rfc14.htm#14.1.
voila ce que je reçois quand lynx se connecte sur mon serveur:
"GET / HTTP/1.0
Host: marge:42000
Accept: text/html, text/plain, text/sgml, */*;q=0.01
Accept-Encoding: gzip, compress
Accept-Language: en
User-Agent: Lynx/2.8.3rel.1 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.5a
"
Marsh Posté le 10-02-2002 à 14:23:16
benou a écrit a écrit : ben ca définit les types mime gérés par le navigateur client. C'est envoyé par le navigateur à chaque requête. je n'es sais pas beaucoup plus et je n'ai jamais rencontré de cas où le serveur HTTP se servait de cette info ... |
j'avais compris que ça définissait les types mimes
je souhaiterais avoir une explication sur le fonctionnement des préférences car je n'ai pas tout compris ce qui était dans la RFC:
si par exemple, le client (browser) prèfère le type MIME image/gif au image/jpeg et que l'image qu'il réclame est en jpeg:
dois-je convertir l'image en gif pour lui envoyer ce qu'il préfère? ou est-ce que je dois juste vérifier qu'il n'existe pas la même image (en me basant sur le nom de fichier) en format gif dans le répertoire de l'image jpeg?
Marsh Posté le 10-02-2002 à 16:40:15
titoine42 a écrit a écrit : si par exemple, le client (browser) prèfère le type MIME image/gif au image/jpeg et que l'image qu'il réclame est en jpeg: dois-je convertir l'image en gif pour lui envoyer ce qu'il préfère? ou est-ce que je dois juste vérifier qu'il n'existe pas la même image (en me basant sur le nom de fichier) en format gif dans le répertoire de l'image jpeg? |
absolument pas !!!! Le browser déclare ce qu'il sait récupérer et si il ne sait pas récupérer le mime type que tu dois lui envoyer qu'il se démerde. Y a peut etre un code d'erreur pour ca. Sinon tu peux utiliser JigSaw qui est un serveur /proxy HTTP1.1 open source.
Installe le sur ton pc (www.w3c.org/jigsaw) et lance le avec l'option -trace. Ensuite va chercher une anim flash que tu as mis sur ton serveur et arrange toi pour utiliser un navig qui a pas de plugin, tu vas voir ce que ca va faire. Ton serveur ne doit pas gérer ca. Si ton client fait un GET sur /images/img0.gif tu en as rien à caler. Un serveur web c'est très con. Il veut ca, bin tu le renvoie, point barre.
Marsh Posté le 10-02-2002 à 16:57:47
ce sont juste des informations qui sont mise à disposition des applications web.
On pourrait imaginer que si l'appli détecte que le navigateur ne sait pas gérer le gif, il ne lui envoie que du jpeg.
Mais comme je disais, je ne connais pas de site qui gère ce genre de choses ...
Marsh Posté le 10-02-2002 à 18:45:22
benou a écrit a écrit : ce sont juste des informations qui sont mise à disposition des applications web. On pourrait imaginer que si l'appli détecte que le navigateur ne sait pas gérer le gif, il ne lui envoie que du jpeg. Mais comme je disais, je ne connais pas de site qui gère ce genre de choses ... |
quand bien même ca ne servirait à rien. Comment veux tu que le browser s'y retrouve si il a un img src=/images/img0.gif" et qu'il récupère un HTTP reply 200 OK sur /images/img0.jpg
Marsh Posté le 10-02-2002 à 18:48:32
je réitère mon conseil pour toi Titoine. Installe JigSaw et utilise le pour surfer un peu en mode trace. Tu vas voir les messages CLAIREMENT qui s'échange. Je peux te donner un example. Voici ce qu'il me jette lorque je me connecte au forum.
Code :
|
plus clair que ca, y a pas enfin du moins comme 1ere approche, pour voir comment fonctionnent les choses.
[jfdsdjhfuetppo]--Message édité par darklord22--[/jfdsdjhfuetppo]
Marsh Posté le 10-02-2002 à 18:51:19
vous remarquerez avec quelle élégance, j'ai viré mon pass de la trace
Marsh Posté le 10-02-2002 à 19:18:13
darklord22 a écrit a écrit : quand bien même ca ne servirait à rien. Comment veux tu que le browser s'y retrouve si il a un img src=/images/img0.gif" et qu'il récupère un HTTP reply 200 OK sur /images/img0.jpg |
ben je vois pas le problème : le type mime est indiqué dans la réponse => il serait de quelle type d'image il s'agit et comment l'afficher.
Marsh Posté le 10-02-2002 à 19:24:23
vi mais pour les dépendances au niveau code source ce serait pas top. ET puis ce serai contraire à la spec de toutes façons
Marsh Posté le 10-02-2002 à 19:38:25
merci pour vos réponse
je vais examiner ton log Darklord
il semblerait que mozilla n'utilise pas le paramètre de préférence
sinon, avez-vous compris la signification de "accept-extension" dans la grammaire du request-header accept?
Marsh Posté le 10-02-2002 à 14:03:27
Je vais créer un topic unique pour mes questions sur ce protocole car sinon, en quelques jours, la première page de cette section sera remplie avec mes posts
Contexte:
je dois coder un httpd en C conforme à la norme HTTP/1.1 et portable au moins sur NetBSD/i386, Solaris/Sparc, OSF/Alpha
j'utilise lex/yacc (flex et bison pour être précis) pour parser le protocole
1ère question: concernant le request-header "Accept"
voici la syntaxe de la RFC 2616 (selon la norme BNF étendue):
Accept = "Accept" ":"
#( media-range [ accept-params ] )
media-range = ( "*/*"
| ( type "/" "*" )
| ( type "/" subtype )
) *( ";" parameter )
accept-params = ";" "q" "=" qvalue *( accept-extension )
accept-extension = ";" token [ "=" ( token | quoted-string ) ]
J'ai fait quelques tests pour voir comment les browsers utilisaient ce header et voici ce que j'ai remarqué :
- les différents types définis sont séparés par ", "
Est-ce que je peux considérer ce format comme un standart (sachant que les séparations de types ne sont pas précisés dans la RFC)
- je n'ai pas encore trouvé un browser qui utilise le "accept-extension"
Pourriez-vous m'expliquer sont fonctionnement, son utilité avec des exemples si possible?
Comment stockeriez-vous ces informations? (je pensais faire une liste chainée de structures)