[HTTP Header] Content-Size et téléchargement

Hi,

Sur un site sous Débian/Apache, j'ai mis en place des fichiers à télécharger. Dans l'entête HTTP, je spécifie toujours « Content-Type: octet/stream », pour être sure que le fichier sera effectivement téléchargé, et non pas ouvert dans le navigateur. Les téléchargements fonctionnent bien et les fichiers sont bien reçus. Mais ce qui ne fonctionne pas, c'est que le navigateur, autant IE qu'Opera, ne semble pas recevoir l'information anticipée sur la taille du fichier. Lors du téléchargement, il est toujours écrit « taille inconnue ». Pourtant je renvoie bien un « Content-Size: ... » dans l'entête HTTP. La valeur du Content-Size est bien une valeur entière (la taille du fichier en octets). Alors je ne comprends pas pourquoi la taille du télécharement n'est pas récupérée ... Quand je télécharge sur d'autres sites, le navigateur reçoit pourtant bien cette information avant de commencer l'enregistrement.

Est-il possible que le serveur Apache filtre les entêtes HTTP et interdise l'envoie de Content-Size ?

Merci par avance pour tous éclairages, même quelqu'onques :)

J'ai trouvé la réponse : il ne faut pas utiliser Content-Size, mais Content-Length. Content-Size n'existe pas. J'ai vérifié dans la référence de HTTP1.1.

Je vois souvent aussi des code du genre « Content-Type: octetr-stream » ou « Ccontent-Type: octet/stream »... vérification faite dans la références MIME, c'est en fait « Content-Type: application/octet-stream » qu'il faut en fait employer.

J'en profite pour faire un commenairte personnel : les référence sur le PHP ne sont pas des référence sur HTTP. A certaines réponses auxquelles ont répond parfois par « il faut le faire en php », on devrait répondre par « il faut le faire en http ». Et faire de l'http et du php, ce n'est pas la même chose (ce même shéma s'applique dans bien d'autre cas : par exemple, on ne devrait pas dire je programme du windows en c/c++, mais je programme avec l'api windows... c'est pas la même chose).

Ce fameux Content-Size qui m'a induit en erreur, est pourtant trés répandu sur le net, et surtout dans les tutos et forums sur le php. L'éloignement des références réelles n'est pas toujours sans conscéquences...

D'ailleurs, plusieurs autres champs que j'ai vu sur des site sur le php, semble ne pas exister en HTTP1.1, et semble donc être de pures inventions (à moins qu'il n'y ai une autre version de HTTP ?) je cite entre autre : Content-URL (qui existe, mais c'est en fait Content-Location... Content-URL n'existe pas), Content-Version, Content-Provider, Content-Name... tous ces champs n'existe absolument pas en php...

Et je suis bien porté à croire que ce sont des documentations mensongères, parce qu'aprés avoir remplacé Content-Size par Content-Length, j'ai bien constaté que ça marche! Une question : les gens qui donnent des codes avec des Content-Size par exemple.. les ont-ils/elles essayé ? Ces gens le prétendent... ils/elles l'ont surement fait... mais quand à savoir s'ils/elles ont controlté que ça marche...

Moralité : toujours s'en tenir au références intiales.

Pour ceux/celles qui s'interessent au MIME, le Content-Type peut prendre deux paramètres supplémentaire. Le premier, est un second indicateur de type concrêt, mais qui n'est pas interpréter par les user-agent, et qui est à destination de l'utilisateur/rice humain(e) (si encore l'user-agent lui permet d'acceder à cette information). Ce second paramètre peut-être par exemple « Audio MP3 »... C'est utile quand justement on envoie un fichier avec un content-type application/octet-stream. Un troisième argument peut encore venir, qui est un entier de 1 à 7. Cette entier donne le padding éventuellement ajouter, en bits (et non pas bytes) pour arrondire le transfert à un nombre de bits multiple de 8, car sur le net, l'élément atomique des transfert est le byte, qui est de 8 bits. C'est utile si un serveur sur un système où l'octet est différent de 8 bits, envoie un fichier par le net. Par exemple, une machine où l'octer fait 7 bits, qui enverra un fichier de 2 octets, enverra donc 14 bits, fera un transfert de 16 bits, et indiquera donc un padding de 2 bits.

Un exemple : « Content-Type: application/octer-stream; MP3; 2 ». Notez bien la présence du point-vigule (semi-colon), pour séparer les argument optionels supplémentaires.