Enregistrer

Bonjour luigifab, aucun soucis pour moi pour l'ouvrir ou le télécharger (mais j'ai un pc qui va bien et la fibre), ça a pris 3 secondes, mais près de 15Mo 🤢 pour le fichier quand même. C'est soit un problème de matériel soit un problème de connexion. C'est pour faire quoi exactement ? ouvrir le fichier ? le télécharger ? travailler dessus ?

Moi j'obtiens que 3,74 Mo en 21s quand je l'ouvre dans editgpx.
Ou encore 7,08 Mo en 26s.

J'ai l'ADSL de la campagne.

Par contre quand je télécharge depuis la fiche, j'ai bien les 14,9 Mo.
J'utilise Firefox 104, mais la semaine dernière ça le faisait aussi avec Firefox 103.

Je sais pas comment c'est fait dans download.php, mais c'est pas possible de gzencode(le gpx) + add header content-encoding gzip ?

EDIT: Du coup en pensant à ça j'ai pensé au plus beau des sites ecommerce qu'on nomme Magento 1...
Je vois que dans un de mes contrôleurs je peux :

$response->setHeader('Content-Type', 'application/json', true);
$response->setHeader('Content-Encoding', 'gzip', true);
$response->setHeader('Cache-Control', 'no-cache, must-revalidate', true);
$response->setBody(gzencode(json_encode(..., 9)));

Et à première vu c'est vachement bien.

Le transfert est déjà compressé br. Le téléchargement de fichiers peut-être un peu long car il y a une phase de préparation :

1. vérifier que vous avez bien les droits pour récupérer le fichier.
2. Ouvrir le fichier pour récupérer toutes les altitudes si besoin : sur votre fichier c'est un problème car il est à cheval entre les 2 bases, et comme le choix de la base se fait en gros sur le premier point, il partie de vos traces n'ont pas d'altitude, et donc le système essaie à tout moment de les récupérer (ouverture dans editgpx, téléchargement, ....)
3. Vérifier qu'il n'y a pas de zone de confidentialité liée à ce fichier et effacer les parties dans la zone le cas échéant

Bref, plus le fichier est lourd plus ça prend du temps. Ensuite le téléchargement commence, et je confirme qu'il est bien compressé, pour s'en convaincre il suffit de regarder la quantité de donnée transférée, bien inférieure à la taille de la ressource.

A quand bien même que ça ne fonctionne plus chez moi.
Je n'ai pas de zone de confidentialité, et je suis le créateur de la trace avec editgpx.

Je vais sur ma trace, je clic sur actions / charger la trace dans editgpx :
- https://www.zupimages.net/up/22/34/aqkf.png

J'attends, j'obtiens 200 ok :
- https://zupimages.net/up/22/34/0isx.png
- https://zupimages.net/up/22/34/wf36.png

Par contre, en même temps ça crash dans la console :
- https://zupimages.net/up/22/34/cjzu.png

Je peux attendre encore longtemps, il ne se passera rien.
Et oui j'aurais bien aimé désactiver les altitudes dans ce fichier...

--

Avec un autre fichier plus petit, ça passe, par contre pour moi le fichier n'est pas compressé :
- https://zupimages.net/up/22/34/834e.png
- https://zupimages.net/up/22/34/fbu7.png
- https://zupimages.net/up/22/34/rvpv.png

--

D'ailleurs ma curiosité me démange, car chez moi avec wget j'ai pour un fichier de 1 Mo :

fabrice[AT]mario🤨$ wget --header="accept-encoding: gzip" https://www.luigifab.fr/voyage/2019/2019-06-01.gpx?75b8d960cd
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 113654 (111K) [application/gpx+xml]
Sauvegarde en : « 2019-06-01.gpx?75b8d960cd »

2019-06-01.gpx?75b8d960cd 100%[==============================================================================>] 110,99K 331KB/s ds 0,3s

fabrice[AT]mario🤨$ wget https://www.luigifab.fr/voyage/2019/2019-06-01.gpx?75b8d960cd
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 1050431 (1,0M) [application/gpx+xml]
Sauvegarde en : « 2019-06-01.gpx?75b8d960cd.1 »

2019-06-01.gpx?75b8d960cd.1 100%[==============================================================================>] 1,00M 287KB/s ds 3,6s

Et avec ma trace qui pose problème (mais uniquement dans editgpx, car en faisant un téléchargement seul ça pose pas de soucis) :

fabrice[AT]mario🤨$ wget --header="accept-encoding: gzip" https://www.visugpx.com/download.php?id=PleCWYz6ai
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : non indiqué [application/gpx+xml]
Sauvegarde en : « download.php?id=PleCWYz6ai »

download.php?id=PleCWYz6ai [ <=> ] 15,73M 279KB/s ds 57s


Même chose avec br et sans le header, 15,7 Mo téléchargé. 😭

Alors oui, le fichier téléchargé en pièce jointe n'est effectivement pas compressé dans vos exemples. Malgré mes essais je n'y parviens pas. Les pages sont bien enconnées, mais pas les pièces jointes. Je me renseigne.

Et oui je constate la même chose sur mes tests. J'ai beau ajouter des instructions de compression, rien n'y fait, les pièces jointes ne le sont pas
J'ai mailé mon hébergeur.

Donc réponse, bloqué car seuls certains types sont compressés avant l'envoi. J'ai modifié le type mime, pour le passer à txt (gpx avant), c'est beaucoup mieux, reste à voir comment se comportent certains systèmes lors de l'ouverture du fichier

Ok, mince alors, me voilà très triste !

?
C'était effectif, mais ça pose des problèmes avec garmin qui ne reconnaît plus les fichiers. Je vais faire des tests et éventuellement faire marche arrière..

As-tu essayé des sous-classes MIME?
J'ai trouvé quelque chose d'intéressant ici.
Avec un peu de chance, en déclarant le type GPX et une sous-classe text, peut-être que la compression marcherait?
<sub-class-of type="text/xml"/>

Une piste mais j'avoue être mal placé pour donner le moindre conseil.

Partagerais tu le bout de ton fichier download.php qui fait le téléchargement ?

Ce n'est pas un pb de script, c'est un pb lié au type déclaré. Le serveur se base sur le type pour comprimer html, CSS, js, txt, mais ne comprime pas les types inconnus ou les images car déjà comprimes.

Garmin se base aussi sur le type.

Il faut donc que je trouve un type qui soit reconnus des 2 côtés.

Normalement gpx = allplication/gpx+xml, mais ça pourrait très bien être text/xml, car c'est du texte.

Merci Angstrom, je regarde les sous classes mime.

Je ne sais pas comment c'est fait, si je dis pas de bêtise, le serveur ne compressera pas le fichier d'un "content-disposition: attachment;", quelque soit le mime type.
C'est pour ça que je proposais d'ajouter quelque chose comme " $response->setHeader('Content-Encoding', 'gzip', true);", et lors de l'envoi au lieu de faire un "readfile()" ou équivalent, faire quelque chose comme " $response->setBody(gzencode($fileContent, 9));".