quelques fois certains fichiers du net non pas d'extension, ça peut être
du html ou une image.
pour savoir si c'est du html je peux utiliser lynx :
$ lynx -head -dump url
par exemple :
zsh-% lynx -head -dump http://dico-cuisine.fr/news/orecchiette
HTTP/1.1 200 OK
Date: Tue, 08 Jun 2010 05:31:05 GMT
Server: Apache/1.3.41 (Unix) mod_perl/1.31
Expires: Mon, 07 Jun 2010 05:31:06 GMT
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: b=88.183.202.165_1275975066; path=/; expires=Mon,
04-Mar-2013 05:31:
06 GMT
Connection: close
j'ai essayé avec une image ça donne pas grand chose d'intéressant :
lynx -head -dump http://88.183.202.165/valid-xhtml1
me donne :
zsh-% lynx -head -dump http://88.183.202.165/valid-xhtml1
HTTP/1.1 200 OK
Date: Tue, 08 Jun 2010 05:45:18 GMT
Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8l DAV/2
PHP/5.3.1
Last-Modified: Sun, 09 May 2010 08:35:02 GMT
ETag: "b15161-116-486252b1bd980"
Accept-Ranges: bytes
Content-Length: 278
Connection: close
Content-Type: text/plain
--------------^^^^^^^^^^^
bien sûr je souhaiterais que ça marche sur n'importe quel serveur.
euh le but de la manip étant d'ajouter la "bonne" extension à un fichier
qui n'en a pas.
--
« Le verbe aimer est difficile à conjuguer :
son passé n'est pas simple, son présent n'est qu'indicatif,
et son futur est toujours conditionnel. »
(Jean Cocteau)
Là c'est clairement un bug sur le serveur, malheureusement non détectable par l'auteur du site s'il n'utilise que Internet Explorer pour ses tests.
bien sûr je souhaiterais que ça marche sur n'importe quel serveur.
euh le but de la manip étant d'ajouter la "bonne" extension à un fichier qui n'en a pas.
Tiens, voici de quoi t'amuser : http://www.astro.keele.ac.uk/oldusers/rno/Computing/File_magic.html
Si tu ne veux pas l'encoder toi-même, sache que la commande file sur Unix (ou assimilé) peut faire le travail pour toi : _$ file /etc/passwd /etc/passwd: ASCII text _$ file un_pdf_sans_extension un_pdf_sans_extension: PDF document, version 1.4 _$ file une_image une_image: JPEG image data, JFIF standard 1.02 _$ file autre_image autre_image: GIF image data, version 89a, 529 x 87
Cordialement, -- Olivier Miakinen
Le 08/06/2010 07:55, Une Bévue a écrit :
quelques fois certains fichiers du net non pas d'extension, ça peut être
du html ou une image.
... ou un fichier d'archive, ou un exécutable, ou n'importe quoi d'autre.
pour savoir si c'est du html je peux utiliser lynx :
$ lynx -head -dump url
Là c'est clairement un bug sur le serveur, malheureusement non
détectable par l'auteur du site s'il n'utilise que Internet Explorer
pour ses tests.
bien sûr je souhaiterais que ça marche sur n'importe quel serveur.
euh le but de la manip étant d'ajouter la "bonne" extension à un fichier
qui n'en a pas.
Tiens, voici de quoi t'amuser :
http://www.astro.keele.ac.uk/oldusers/rno/Computing/File_magic.html
Si tu ne veux pas l'encoder toi-même, sache que la commande file sur
Unix (ou assimilé) peut faire le travail pour toi :
_$ file /etc/passwd
/etc/passwd: ASCII text
_$ file un_pdf_sans_extension
un_pdf_sans_extension: PDF document, version 1.4
_$ file une_image
une_image: JPEG image data, JFIF standard 1.02
_$ file autre_image
autre_image: GIF image data, version 89a, 529 x 87
Là c'est clairement un bug sur le serveur, malheureusement non détectable par l'auteur du site s'il n'utilise que Internet Explorer pour ses tests.
bien sûr je souhaiterais que ça marche sur n'importe quel serveur.
euh le but de la manip étant d'ajouter la "bonne" extension à un fichier qui n'en a pas.
Tiens, voici de quoi t'amuser : http://www.astro.keele.ac.uk/oldusers/rno/Computing/File_magic.html
Si tu ne veux pas l'encoder toi-même, sache que la commande file sur Unix (ou assimilé) peut faire le travail pour toi : _$ file /etc/passwd /etc/passwd: ASCII text _$ file un_pdf_sans_extension un_pdf_sans_extension: PDF document, version 1.4 _$ file une_image une_image: JPEG image data, JFIF standard 1.02 _$ file autre_image autre_image: GIF image data, version 89a, 529 x 87
Cordialement, -- Olivier Miakinen
unbewusst.sein
Olivier Miakinen <om+ wrote:
Tiens, voici de quoi t'amuser : http://www.astro.keele.ac.uk/oldusers/rno/Computing/File_magic.html
Si tu ne veux pas l'encoder toi-même, sache que la commande file sur Unix (ou assimilé) peut faire le travail pour toi :
ouais, donc ça signifie que je ne peux connaître le type de fichier qu'après l'avoir téléchargé.
tiens c'est curieux le js n'est pas reconnu, sinon comme "text/plain"... le css comme "text/x-c" bon, no comment. -- « Le verbe aimer est difficile à conjuguer : son passé n'est pas simple, son présent n'est qu'indicatif, et son futur est toujours conditionnel. » (Jean Cocteau)
Olivier Miakinen <om+news@miakinen.net> wrote:
Tiens, voici de quoi t'amuser :
http://www.astro.keele.ac.uk/oldusers/rno/Computing/File_magic.html
Si tu ne veux pas l'encoder toi-même, sache que la commande file sur
Unix (ou assimilé) peut faire le travail pour toi :
ouais, donc ça signifie que je ne peux connaître le type de fichier
qu'après l'avoir téléchargé.
tiens c'est curieux le js n'est pas reconnu, sinon comme "text/plain"...
le css comme "text/x-c" bon, no comment.
--
« Le verbe aimer est difficile à conjuguer :
son passé n'est pas simple, son présent n'est qu'indicatif,
et son futur est toujours conditionnel. »
(Jean Cocteau)
tiens c'est curieux le js n'est pas reconnu, sinon comme "text/plain"... le css comme "text/x-c" bon, no comment. -- « Le verbe aimer est difficile à conjuguer : son passé n'est pas simple, son présent n'est qu'indicatif, et son futur est toujours conditionnel. » (Jean Cocteau)
bruno666
Olivier Miakinen a écrit :
Le 08/06/2010 07:55, Une Bévue a écrit :
quelques fois certains fichiers du net non pas d'extension, ça peut être du html ou une image.
... ou un fichier d'archive, ou un exécutable, ou n'importe quoi d'autre.
pour savoir si c'est du html je peux utiliser lynx : $ lynx -head -dump url
Là c'est clairement un bug sur le serveur, malheureusement non détectable par l'auteur du site s'il n'utilise que Internet Explorer pour ses tests.
Je ne crois pas que ce soit un bug. Un serveur Apache est configuré par défaut pour servir un contenu dont il ne peut déterminer le type en text/plain.
Je ne vois pas comment modifier ce comportement sans intervenir sur la configuration du serveur ou sans modifier les en-tes http avec un script PHP par exemple.
-- Bruno
Olivier Miakinen a écrit :
Le 08/06/2010 07:55, Une Bévue a écrit :
quelques fois certains fichiers du net non pas d'extension, ça peut être
du html ou une image.
... ou un fichier d'archive, ou un exécutable, ou n'importe quoi d'autre.
pour savoir si c'est du html je peux utiliser lynx :
$ lynx -head -dump url
Là c'est clairement un bug sur le serveur, malheureusement non
détectable par l'auteur du site s'il n'utilise que Internet Explorer
pour ses tests.
Je ne crois pas que ce soit un bug. Un serveur Apache est configuré par
défaut pour servir un contenu dont il ne peut déterminer le type en
text/plain.
Je ne vois pas comment modifier ce comportement sans intervenir sur la
configuration du serveur ou sans modifier les en-tes http avec un script PHP
par exemple.
Là c'est clairement un bug sur le serveur, malheureusement non détectable par l'auteur du site s'il n'utilise que Internet Explorer pour ses tests.
Je ne crois pas que ce soit un bug. Un serveur Apache est configuré par défaut pour servir un contenu dont il ne peut déterminer le type en text/plain.
Je ne vois pas comment modifier ce comportement sans intervenir sur la configuration du serveur ou sans modifier les en-tes http avec un script PHP par exemple.
-- Bruno
Olivier Miakinen
Le 08/06/2010 09:35, Une Bévue a écrit :
Tiens, voici de quoi t'amuser : http://www.astro.keele.ac.uk/oldusers/rno/Computing/File_magic.html
Si tu ne veux pas l'encoder toi-même, sache que la commande file sur Unix (ou assimilé) peut faire le travail pour toi :
ouais, donc ça signifie que je ne peux connaître le type de fichier qu'après l'avoir téléchargé.
Si le serveur ne te fournit pas l'information d'une manière ou d'une autre avant que tu ne le télécharges, alors tu ne pourras avoir une idée du type de fichier qu'après avoir téléchargé au moins les quelques premiers octets (10 octets au maximum dans la liste ci-dessus pour le type « gimp xcf »).
Si j'en crois la norme, ça doit pouvoir se faire avec « bytes=0-9 » : <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35>.
Cela dit, je ne vois pas comment tu pourrais (je te cite) « ajouter la "bonne" extension à un fichier qui n'en a pas » si tu n'as pas le fichier en entier.
[...]
tiens c'est curieux le js n'est pas reconnu, sinon comme "text/plain"... le css comme "text/x-c" bon, no comment.
Encore une fois c'est une question de configuration du serveur.
Le 08/06/2010 09:35, Une Bévue a écrit :
Tiens, voici de quoi t'amuser :
http://www.astro.keele.ac.uk/oldusers/rno/Computing/File_magic.html
Si tu ne veux pas l'encoder toi-même, sache que la commande file sur
Unix (ou assimilé) peut faire le travail pour toi :
ouais, donc ça signifie que je ne peux connaître le type de fichier
qu'après l'avoir téléchargé.
Si le serveur ne te fournit pas l'information d'une manière ou d'une
autre avant que tu ne le télécharges, alors tu ne pourras avoir une idée
du type de fichier qu'après avoir téléchargé au moins les quelques
premiers octets (10 octets au maximum dans la liste ci-dessus pour le
type « gimp xcf »).
Si j'en crois la norme, ça doit pouvoir se faire avec « bytes=0-9 » :
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35>.
Cela dit, je ne vois pas comment tu pourrais (je te cite) « ajouter la
"bonne" extension à un fichier qui n'en a pas » si tu n'as pas le
fichier en entier.
[...]
tiens c'est curieux le js n'est pas reconnu, sinon comme "text/plain"...
le css comme "text/x-c" bon, no comment.
Encore une fois c'est une question de configuration du serveur.
Tiens, voici de quoi t'amuser : http://www.astro.keele.ac.uk/oldusers/rno/Computing/File_magic.html
Si tu ne veux pas l'encoder toi-même, sache que la commande file sur Unix (ou assimilé) peut faire le travail pour toi :
ouais, donc ça signifie que je ne peux connaître le type de fichier qu'après l'avoir téléchargé.
Si le serveur ne te fournit pas l'information d'une manière ou d'une autre avant que tu ne le télécharges, alors tu ne pourras avoir une idée du type de fichier qu'après avoir téléchargé au moins les quelques premiers octets (10 octets au maximum dans la liste ci-dessus pour le type « gimp xcf »).
Si j'en crois la norme, ça doit pouvoir se faire avec « bytes=0-9 » : <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35>.
Cela dit, je ne vois pas comment tu pourrais (je te cite) « ajouter la "bonne" extension à un fichier qui n'en a pas » si tu n'as pas le fichier en entier.
[...]
tiens c'est curieux le js n'est pas reconnu, sinon comme "text/plain"... le css comme "text/x-c" bon, no comment.
Encore une fois c'est une question de configuration du serveur.
Là c'est clairement un bug sur le serveur, malheureusement non détectable par l'auteur du site s'il n'utilise que Internet Explorer pour ses tests.
Je ne crois pas que ce soit un bug. Un serveur Apache est configuré par défaut pour servir un contenu dont il ne peut déterminer le type en text/plain.
Ben si, c'est un bug « sur le serveur » même si ce n'est pas un bug « du logiciel serveur ». Je voulais dire que c'est de la responsabilité du webmestre *côté serveur* de faire en sorte que les différents types de fichiers soient correctement déclarés.
Noter qu'un même fichier peut avoir différentes déclarations différentes selon l'usage qu'on veut en faire : par exemple, un code HTML peut être déclaré en "text/html" quand il est censé être interprété, mais aussi en "text/plain" si le but est d'afficher son code source (malheureusement je crois que certaines versions d'Internet Explorer s'en fichent).
Je ne vois pas comment modifier ce comportement sans intervenir sur la configuration du serveur ou sans modifier les en-têtes http avec un script PHP par exemple.
Là c'est clairement un bug sur le serveur, malheureusement non
détectable par l'auteur du site s'il n'utilise que Internet Explorer
pour ses tests.
Je ne crois pas que ce soit un bug. Un serveur Apache est configuré par
défaut pour servir un contenu dont il ne peut déterminer le type en
text/plain.
Ben si, c'est un bug « sur le serveur » même si ce n'est pas un bug
« du logiciel serveur ». Je voulais dire que c'est de la responsabilité
du webmestre *côté serveur* de faire en sorte que les différents types
de fichiers soient correctement déclarés.
Noter qu'un même fichier peut avoir différentes déclarations différentes
selon l'usage qu'on veut en faire : par exemple, un code HTML peut être
déclaré en "text/html" quand il est censé être interprété, mais aussi en
"text/plain" si le but est d'afficher son code source (malheureusement
je crois que certaines versions d'Internet Explorer s'en fichent).
Je ne vois pas comment modifier ce comportement sans intervenir sur la
configuration du serveur ou sans modifier les en-têtes http avec un script PHP
par exemple.
Là c'est clairement un bug sur le serveur, malheureusement non détectable par l'auteur du site s'il n'utilise que Internet Explorer pour ses tests.
Je ne crois pas que ce soit un bug. Un serveur Apache est configuré par défaut pour servir un contenu dont il ne peut déterminer le type en text/plain.
Ben si, c'est un bug « sur le serveur » même si ce n'est pas un bug « du logiciel serveur ». Je voulais dire que c'est de la responsabilité du webmestre *côté serveur* de faire en sorte que les différents types de fichiers soient correctement déclarés.
Noter qu'un même fichier peut avoir différentes déclarations différentes selon l'usage qu'on veut en faire : par exemple, un code HTML peut être déclaré en "text/html" quand il est censé être interprété, mais aussi en "text/plain" si le but est d'afficher son code source (malheureusement je crois que certaines versions d'Internet Explorer s'en fichent).
Je ne vois pas comment modifier ce comportement sans intervenir sur la configuration du serveur ou sans modifier les en-têtes http avec un script PHP par exemple.
Nous sommes bien d'accord.
Cordialement, -- Olivier Miakinen
unbewusst.sein
Olivier Miakinen <om+ wrote:
Si le serveur ne te fournit pas l'information d'une manière ou d'une autre avant que tu ne le télécharges, alors tu ne pourras avoir une idée du type de fichier qu'après avoir téléchargé au moins les quelques premiers octets (10 octets au maximum dans la liste ci-dessus pour le type « gimp xcf »).
Si j'en crois la norme, ça doit pouvoir se faire avec « bytes=0-9 » : <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35>.
ok mais bon : « However, not all clients and servers need to support byte- range operations. »
c'est donc inutilisable.
Cela dit, je ne vois pas comment tu pourrais (je te cite) « ajouter la "bonne" extension à un fichier qui n'en a pas » si tu n'as pas le fichier en entier.
moi non plus d'où ma perplexité vis à vis de certains sites qui envoients des fichiers et images sans extension.
m'enfin, avec file --mime-time je suis satisfait, quand je trouve qqc de plausible j'ajoute l'extension, sinon je ne fais rien.
> [...] > > tiens c'est curieux le js n'est pas reconnu, sinon comme "text/plain"... > le css comme "text/x-c" bon, no comment.
Encore une fois c'est une question de configuration du serveur.
ouais je suis d'accord là-dessus.
-- « Le verbe aimer est difficile à conjuguer : son passé n'est pas simple, son présent n'est qu'indicatif, et son futur est toujours conditionnel. » (Jean Cocteau)
Olivier Miakinen <om+news@miakinen.net> wrote:
Si le serveur ne te fournit pas l'information d'une manière ou d'une
autre avant que tu ne le télécharges, alors tu ne pourras avoir une idée
du type de fichier qu'après avoir téléchargé au moins les quelques
premiers octets (10 octets au maximum dans la liste ci-dessus pour le
type « gimp xcf »).
Si j'en crois la norme, ça doit pouvoir se faire avec « bytes=0-9 » :
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35>.
ok mais bon :
« However, not all clients and servers need to support byte- range
operations. »
c'est donc inutilisable.
Cela dit, je ne vois pas comment tu pourrais (je te cite) « ajouter la
"bonne" extension à un fichier qui n'en a pas » si tu n'as pas le
fichier en entier.
moi non plus d'où ma perplexité vis à vis de certains sites qui
envoients des fichiers et images sans extension.
m'enfin, avec file --mime-time je suis satisfait, quand je trouve qqc de
plausible j'ajoute l'extension, sinon je ne fais rien.
> [...]
>
> tiens c'est curieux le js n'est pas reconnu, sinon comme "text/plain"...
> le css comme "text/x-c" bon, no comment.
Encore une fois c'est une question de configuration du serveur.
ouais je suis d'accord là-dessus.
--
« Le verbe aimer est difficile à conjuguer :
son passé n'est pas simple, son présent n'est qu'indicatif,
et son futur est toujours conditionnel. »
(Jean Cocteau)
Si le serveur ne te fournit pas l'information d'une manière ou d'une autre avant que tu ne le télécharges, alors tu ne pourras avoir une idée du type de fichier qu'après avoir téléchargé au moins les quelques premiers octets (10 octets au maximum dans la liste ci-dessus pour le type « gimp xcf »).
Si j'en crois la norme, ça doit pouvoir se faire avec « bytes=0-9 » : <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35>.
ok mais bon : « However, not all clients and servers need to support byte- range operations. »
c'est donc inutilisable.
Cela dit, je ne vois pas comment tu pourrais (je te cite) « ajouter la "bonne" extension à un fichier qui n'en a pas » si tu n'as pas le fichier en entier.
moi non plus d'où ma perplexité vis à vis de certains sites qui envoients des fichiers et images sans extension.
m'enfin, avec file --mime-time je suis satisfait, quand je trouve qqc de plausible j'ajoute l'extension, sinon je ne fais rien.
> [...] > > tiens c'est curieux le js n'est pas reconnu, sinon comme "text/plain"... > le css comme "text/x-c" bon, no comment.
Encore une fois c'est une question de configuration du serveur.
ouais je suis d'accord là-dessus.
-- « Le verbe aimer est difficile à conjuguer : son passé n'est pas simple, son présent n'est qu'indicatif, et son futur est toujours conditionnel. » (Jean Cocteau)
Olivier Miakinen
Le 08/06/2010 13:07, Une Bévue a écrit :
Cela dit, je ne vois pas comment tu pourrais (je te cite) « ajouter la "bonne" extension à un fichier qui n'en a pas » si tu n'as pas le fichier en entier.
moi non plus d'où ma perplexité vis à vis de certains sites qui envoients des fichiers et images sans extension.
Gnîîî ??? Avec une URL qui ne se termine pas par « pointquelquechose », ou sans type Mime dans l'entête Content-Type ? Quel est ton besoin réel au fond ? Parce que du moment qu'une image JPEG est envoyée avec le Content-Type "image/jpeg", peu importe que son nom apparent se termine en .gif, en .doc ou en .mp3 !
Le 08/06/2010 13:07, Une Bévue a écrit :
Cela dit, je ne vois pas comment tu pourrais (je te cite) « ajouter la
"bonne" extension à un fichier qui n'en a pas » si tu n'as pas le
fichier en entier.
moi non plus d'où ma perplexité vis à vis de certains sites qui
envoients des fichiers et images sans extension.
Gnîîî ??? Avec une URL qui ne se termine pas par « pointquelquechose »,
ou sans type Mime dans l'entête Content-Type ? Quel est ton besoin réel
au fond ? Parce que du moment qu'une image JPEG est envoyée avec le
Content-Type "image/jpeg", peu importe que son nom apparent se termine
en .gif, en .doc ou en .mp3 !
Cela dit, je ne vois pas comment tu pourrais (je te cite) « ajouter la "bonne" extension à un fichier qui n'en a pas » si tu n'as pas le fichier en entier.
moi non plus d'où ma perplexité vis à vis de certains sites qui envoients des fichiers et images sans extension.
Gnîîî ??? Avec une URL qui ne se termine pas par « pointquelquechose », ou sans type Mime dans l'entête Content-Type ? Quel est ton besoin réel au fond ? Parce que du moment qu'une image JPEG est envoyée avec le Content-Type "image/jpeg", peu importe que son nom apparent se termine en .gif, en .doc ou en .mp3 !
unbewusst.sein
Olivier Miakinen <om+ wrote:
Gnîîî ??? Avec une URL qui ne se termine pas par « pointquelquechose », ou sans type Mime dans l'entête Content-Type ? Quel est ton besoin réel au fond ? Parce que du moment qu'une image JPEG est envoyée avec le Content-Type "image/jpeg", peu importe que son nom apparent se termine en .gif, en .doc ou en .mp3 !
quand je fais le ménage dans mes dossiers, c'est plus facile de se repérer. rn utilisation online je m'en fiche. -- « Le verbe aimer est difficile à conjuguer : son passé n'est pas simple, son présent n'est qu'indicatif, et son futur est toujours conditionnel. » (Jean Cocteau)
Olivier Miakinen <om+news@miakinen.net> wrote:
Gnîîî ??? Avec une URL qui ne se termine pas par « pointquelquechose »,
ou sans type Mime dans l'entête Content-Type ? Quel est ton besoin réel
au fond ? Parce que du moment qu'une image JPEG est envoyée avec le
Content-Type "image/jpeg", peu importe que son nom apparent se termine
en .gif, en .doc ou en .mp3 !
quand je fais le ménage dans mes dossiers, c'est plus facile de se
repérer. rn utilisation online je m'en fiche.
--
« Le verbe aimer est difficile à conjuguer :
son passé n'est pas simple, son présent n'est qu'indicatif,
et son futur est toujours conditionnel. »
(Jean Cocteau)
Gnîîî ??? Avec une URL qui ne se termine pas par « pointquelquechose », ou sans type Mime dans l'entête Content-Type ? Quel est ton besoin réel au fond ? Parce que du moment qu'une image JPEG est envoyée avec le Content-Type "image/jpeg", peu importe que son nom apparent se termine en .gif, en .doc ou en .mp3 !
quand je fais le ménage dans mes dossiers, c'est plus facile de se repérer. rn utilisation online je m'en fiche. -- « Le verbe aimer est difficile à conjuguer : son passé n'est pas simple, son présent n'est qu'indicatif, et son futur est toujours conditionnel. » (Jean Cocteau)
SAM
Le 6/8/10 1:07 PM, Une Bévue a écrit :
moi non plus d'où ma perplexité vis à vis de certains sites qui envoients des fichiers et images sans extension.
Le lien n'a pas d'obligation à stipuler l'extension bien que le fichier lui en a tout de même une.
M'enfin c'est pas pire que lorsqu'on reçoit un fichier "truc.php" au lieu de "machin.pdf" ... :-( (le changement de l'extension du fichier reçu rétablissant la bonne marche du dit fichier même si son nom n'est pas parlant) (je passe un temps fou à corriger de tels pdf reçus - et le nom et l'extension)
Il n'y aurait pas que la config du serveur mais aussi le caraboustillage du php servant les fichiers à télécharger. (vu comme ça là de ma chaise) -- sm
Le 6/8/10 1:07 PM, Une Bévue a écrit :
moi non plus d'où ma perplexité vis à vis de certains sites qui
envoients des fichiers et images sans extension.
Le lien n'a pas d'obligation à stipuler l'extension
bien que le fichier lui en a tout de même une.
M'enfin c'est pas pire que lorsqu'on reçoit un fichier "truc.php"
au lieu de "machin.pdf" ... :-(
(le changement de l'extension du fichier reçu rétablissant la bonne
marche du dit fichier même si son nom n'est pas parlant)
(je passe un temps fou à corriger de tels pdf reçus - et le nom et
l'extension)
Il n'y aurait pas que la config du serveur mais aussi le caraboustillage
du php servant les fichiers à télécharger.
(vu comme ça là de ma chaise)
--
sm
moi non plus d'où ma perplexité vis à vis de certains sites qui envoients des fichiers et images sans extension.
Le lien n'a pas d'obligation à stipuler l'extension bien que le fichier lui en a tout de même une.
M'enfin c'est pas pire que lorsqu'on reçoit un fichier "truc.php" au lieu de "machin.pdf" ... :-( (le changement de l'extension du fichier reçu rétablissant la bonne marche du dit fichier même si son nom n'est pas parlant) (je passe un temps fou à corriger de tels pdf reçus - et le nom et l'extension)
Il n'y aurait pas que la config du serveur mais aussi le caraboustillage du php servant les fichiers à télécharger. (vu comme ça là de ma chaise) -- sm
SAM
Le 6/8/10 1:43 PM, Une Bévue a écrit :
Olivier Miakinen <om+ wrote:
Gnîîî ??? Avec une URL qui ne se termine pas par « pointquelquechose », ou sans type Mime dans l'entête Content-Type ? Quel est ton besoin réel au fond ? Parce que du moment qu'une image JPEG est envoyée avec le Content-Type "image/jpeg", peu importe que son nom apparent se termine en .gif, en .doc ou en .mp3 !
Heu ... alors ça servirait à quoi de stipuler le type jpeg si finalement c'est du mpeg ? Quelle est la punition à l'arrivée sur son ordinateur ? Le mp3 sera ouvert par Paint ? Et le jpg par MediaPlayer ?
quand je fais le ménage dans mes dossiers, c'est plus facile de se repérer. En utilisation online je m'en fiche.
Tu as des dossiers avec extensions ? Tu classes tes fichiers par types ? et pas pas sujets ?
-- sm
Le 6/8/10 1:43 PM, Une Bévue a écrit :
Olivier Miakinen <om+news@miakinen.net> wrote:
Gnîîî ??? Avec une URL qui ne se termine pas par « pointquelquechose »,
ou sans type Mime dans l'entête Content-Type ? Quel est ton besoin réel
au fond ? Parce que du moment qu'une image JPEG est envoyée avec le
Content-Type "image/jpeg", peu importe que son nom apparent se termine
en .gif, en .doc ou en .mp3 !
Heu ... alors ça servirait à quoi de stipuler le type jpeg si finalement
c'est du mpeg ?
Quelle est la punition à l'arrivée sur son ordinateur ?
Le mp3 sera ouvert par Paint ? Et le jpg par MediaPlayer ?
quand je fais le ménage dans mes dossiers, c'est plus facile de se
repérer. En utilisation online je m'en fiche.
Tu as des dossiers avec extensions ?
Tu classes tes fichiers par types ? et pas pas sujets ?
Gnîîî ??? Avec une URL qui ne se termine pas par « pointquelquechose », ou sans type Mime dans l'entête Content-Type ? Quel est ton besoin réel au fond ? Parce que du moment qu'une image JPEG est envoyée avec le Content-Type "image/jpeg", peu importe que son nom apparent se termine en .gif, en .doc ou en .mp3 !
Heu ... alors ça servirait à quoi de stipuler le type jpeg si finalement c'est du mpeg ? Quelle est la punition à l'arrivée sur son ordinateur ? Le mp3 sera ouvert par Paint ? Et le jpg par MediaPlayer ?
quand je fais le ménage dans mes dossiers, c'est plus facile de se repérer. En utilisation online je m'en fiche.
Tu as des dossiers avec extensions ? Tu classes tes fichiers par types ? et pas pas sujets ?
