Newsgroup: it.comp.lang.javascript
Titolo: [PRO] Files htm.gz: la sfida.

[PRO] Files htm.gz: la sfida.
Un ciao a tutti i partecipanti del newsgroups.
Quella che si è mobilitata nel giro di circa una settimana è una vera e propria task force trasversale aperta a tutte le menti più raffinate e 
smaliziate che operano per diletto o per mestiere in ambito web.
La soluzione del giallo potrebbe essere semplice come potrebbe essere più complessa, non sono in grado di stabilirlo a priori, di certo posso 
affermare che la soluzione di 
questo mistero ha delle implicazioni importanti per tutta la comunità dei websurfers e degli sviluppatori.
La sfida al mistero che cercherò di sintetizzare è stata lanciata su un thread presente nel Forum HTML di 
WWW.HTML.IT
, ed è tuttora ancora 
irrisolta sebbene abbia già totalizzato complessivamente più di 500 contatti.
Mi preme sottolineare che personalmente non ho alcun legame con il forum suddetto, la sfida poteva essere postata direttamente qui, ed ora 
credo sia opportuno tentare di allargare il dominio di partecipazione a quanti più cervelli sia possibile per cercare di capire quale sia la 
soluzione che, se individuata ha dei risvolti molto interessanti per tutti.
Vengo subito al nocciolo della questione precisando che il contributo dei newbies è comunque gradito in termini di feedback statistico sui 
risultati che otterremo, anche se tecnicamente non si hanno le basi tecniche per approcciare il problema. 
La sfida è questa: 
tutti i browser WINDOWS in circolazione (NS4.06+,IE4+,Mozilla0.9+,Opera5+) a prescindere dal sistema operativo win su cui girano hanno la 
capacità intrinseca documentata ampiamente dalle specifiche HTTP/1.1 di visualizzare automaticamente files html compressi usando il formato 
opensource gzip (
www.gzip.org
).
Anche alcuni browser MAC recenti hanno questa capacità ma per meglio circoscrivere il problema possiamo limitarci per ora al mondo WINDOWS.
Tutto ciò significa nella pratica che se il server avverte il browser che ci sta inviando un file compresso in formato gzip, il browser è in 
grado di decomprimerlo on-the-fly e visualizzarlo in maniera completamente trasparente all'utente come qualunque altro file html.
Come capite questo ha delle implicazioni notevoli in termini di occupazione di banda e tempi di download in quanto mediamente un file .htm di 
100KB può ridursi a circa 15KB in formato .htm.gz 
Nella pratica con questo tipo di file .gz il nostro caro modem56K diventa in maniera trasparente (senza alcun software da installare sul 
client) l'equivalente di una connessione ADSL.
E qui sta il mistero: 
http://digilander.iol.it/armageddon99/perl/perl.htm.gz
Il link sopra punta direttamente ad un manuale html di 500KB originali che diventano circa 100KB in formato compresso .gz
La cosa curiosa è che a prescindere dal sistema operativo(WIN9x,ME,XP,2K) o dal browser usato circa la metà degli utenti (me compreso con 
tutti i browser che ho provato su WIN95-modem56K) visualizza automaticamente il file senza richiedere conferme manuali esattamente come 
previsto in pochi secondi come se si avesse a disposizione una connessione ADSL.  
L'altra metà degli utenti invece si vede richiedere messaggio di conferma dal browser.
Aleggia la convinzione che la soluzione del mistero sia una sola, lato client e valida per tutti e che prescinda dall'OS usato ed è questa 
soluzione che si va cercando di scoprire.
Ho preferito non addentrarmi nei dettagli tecnici, per non duplicare il corposo materiale che già abbiamo raccolto sul thread del Forum 
(cercate sul forum HTML la voce 'gzip' o 'magia') e se qualcuno è in grado di individuare la soluzione la posti pubblicamente su questa o 
quella piazza, non ha importanza , l'importante è che diventi patrimonio di tutti.
E naturalmente il trick verrà indicato da quel momento col nome del geniale scopritore...
Grazie a tutti!!
armageddon99

 soluzione che si va cercando di scoprire.
Sapevo del gzip, in PHP ci sono interessanti funzioni a proposito.
Ho banalmente testato con tutti i browser che avevo a disposizione, ma 
non ho ricevuto alcun messaggio di conferma. Idem qualche mio ex-collega 
(solo su  Konqueror gli ha chiesto di fare il download).
Dovremmo saperne di piu'. Ovvero, che tipo di browser sono stati usati, 
su che sistemi.
Intanto, che messaggio di conferma appare?
E poi, su che browser? Ovvero.. La "meta' " di utenti a cui compare tale 
messaggio.. che sistema operativo ha, e con che browser l'ha testato?
L'utente "x" con sistema operativo "y", l'ha provato su IE, NS 4, Opera, 
NS 6? E su tutti gli ha dato il messaggio di conferma? In quel caso, e' 
PROBABILE che non dipenda dal browser.
Non e' pero' automaticamente certo che dipenda dal SO..  magari e' un 
discorso di Proxy o Firewall.
-- 
C'ya,
ZER0
  :. job profile - coder.gfxer.webDesigner
"Quanti angeli danzano sulla punta di uno spillo?"

 [PRO] Files htm.gz: la sfida.
ho provato ad accedere al link, ma mi è apparsa la finestra per salvare
il file!
utilizzo WinXP e IE6!
ho provato ad associare il file (nelle impostazioni di WinXP) a intenet
explore, mentre prima era associato WinRar, ma la situazione non è
cambiata!
forse il problema è che il mio PC si trova in una LAN con proxy?
spero si sveli il mistero!
PauLoX
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG


Non credo sia questo il "mistero", anche se non ho ancora letto i post
HTLM.it...
Molto probabilmente WinRar, come GetRight, effettua un controllo
continuo (con un suo motore sempre attivo) su tutti i files di formato
compresso da lui conosciuti per far in modo da evitare la routine di
salvataggio standart del browser ed avviare la propria.
Anche se cambi le associazioni delle estensioni al browser comunque il
controllo lo riprende WinRar.
Prova a disattivare WinRar e controlla se il tuo browser visualizza
direttamente il file senza richiedere il download, questo credo sia il
vero "mistero".
Ciauzzz Fyts


Ciao ZERO,
grazie del contributo, che aggiungo alla lista di indizi che per ora siamo riusciti a raccogliere.
Personalmente ho difficoltà ad aggredire il problema pur avendo a disposizione packetsnifferTCP/IP, 
tutti i browser win e soprattutto una buona determinazione a risolverlo in quanto non riesco a 
riprodurlo sulla mia macchina win95.
Stiamo raccogliendo quanti più dati possibili sul forum HTML di 
WWW.HTML.IT
, la nascita del thread 
proprio in quel forum come dicevo è casuale (non vorrei si pensasse maliziosamente che si vogliano 
artificiosamente creare contatti sul sito), ho pensato di allargare la base di cervelli facendo 
partecipi anche voi del newsgroup.
L'analisi che stiamo facendo è ristretta a Windows per avere una matrice di indizi più maneggevole 
ma ovviamente risolto l'inghippo in maniera generalizzata in Win , credo sia uno scherzo sistemare 
MAC e gli sistemi, a patto che i browser supportino il content-encoding (la cosa migliore che puoi 
per essere allineato al task è leggerti velocemente il thread sul Forum (non c'è bisogno di 
registrarti)).
Ho un dato che può essere comunque interessante per chi intende aprire un filone Linux: pare che  
Konqueror 2.2.1 (Linux/KDE) supporti pienamente il content-encoding per cui la versione potrebbe fae 
da discriminante.
Riassumendoti i dati parziali raccolti grazie al contributo dei partecipanti al forum, pare che non 
vi sia una correlazione tra browser,tipo di OS win (95,98,ME,XP,2K) e una delle variabili ancora da
verificare è proprio la possibilità che eventuali proxy o firewall filtrino l'intestazione 
proveniente dal server che 'avverte' il browser che il contenuto è 'encoded' (content-
encoding:gzip).
Ma è solo un'ipotesi da verificare e sinceramente mi parrebbe strano che un proxy filtri 
un'informazione così vitale (sarebbe impossibile usare mod_gzip su Apache per esempio).
Se hai tempo e voglia (ritenendoti dalle due righe che hai scritto sufficientemente competente) il 
tuo apporto alla risoluzione del problema è il benvenuto.
Il messaggio di conferma (potessi riprodurlo !!!!) pare che sia lo stesso che ricevi quando cerchi 
di scaricare un comune file .zip per esempio.
L'enigma continua ad essere irrisolto.
Ciao!
armageddon
 
 
 


Ciao Fyts,
questa è un'interessante ipotesi di lavoro, l'intercettazione di un applicativo di decompressione 
durante il downoload con il browser. Se fosse solo questo saremmo a cavallo, aspettiamo qualche 
conferma.
L'ipotesi dell'associazioen con .gz pare perdendo forza in quanto non sembra avere influenza sul 
comportamento dei browser incriminati che continuano a richiedere il download.
Un tuo approfondimento è gradito (dopo un veloce allineamento con il Forum)  !!
Ciao!
armageddon
 

 
http://digilander.iol.it/armageddon99/perl/perl.htm.gz
comunque, provato. Con Opera 6.03, Internet Explorer 5.00 e Mozilla 
0.99 funziona. Con wget 1.7.1 sembra funzionare, ma il file non viene                          
decompresso. L'errore non è di wget, ma tuo, perchè wget non sostiene 
affatto di accettare la codifica gzip:
GET /armageddon99/perl/perl.htm.gz HTTP/1.0
User-Agent: Wget/1.7.1-pre1
Host: 
digilander.iol.it
Accept: */*
Connection: Keep-Alive
salvando il file:
 - Opera 6.03: mantiene l'estensione .gz
 - Internet Explorer 5.00: non usa il nome del file salvando la pagina
   con file->salva, ma salvando la pagina tramite un link, mantiene
   l'estensione .gz
 - Mozilla 0.99: aggiunge l'estensione .html, per cui il file viene
   salvato come perl.htm.gz.html (!)
 - wget 1.7.1: mantiene l'estensione .gz e non decomprime
Di nuovo errore tuo, IMHO, perchè se non specifichi altrimenti nella 
risposta, il nome del file è quello usato nella richiesta. Se vuoi che 
il file venga considerato HTML a tutti gli effetti, specifica il nome 
con l'header Content-Disposition. La soluzione che causa meno problemi 
rimane di comprimere al volo tutte le risposte per i client che 
sostengono di accettare la compressione: non devi cambiare l'header 
Content-Type, non devi cambiare i nomi di file, non causi problemi ai 
client non capaci di decompressione
Per PHP una soluzione potrebbe essere sostituire le funzioni standard 
di output con una che usa l'output gzip per i client che lo accettano, 
e l'output normale altrimenti
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.19. C, C++ and ASM developers
                              and beta testers are welcome!


Vedere le sezioni 3.5, 14.3 e 14.11


 vero "mistero".
per disattivare WinRar intendi eliminare la sua assocazione a quel file
o disinstallarlo?
la prima cosa l'ho gia fatta: ho eliminato l'associazione del formato gz
al file, non č associazto piů a nulla ma mi appare sempre la finestra di
salvataggio!
cmq a mio parere l'ipotesi da te fatta ha delle falle: per esempio sul
mio pc ho associato i file asp al notepad, ma non per questo quando
inserisco l'indirizzo di una pagina asp sul browser mi viene chiesto di
salvarla?


 con l'header Content-Disposition. 
Juliet,
bell'intervento, hai aggiunto elementi di indagine interessanti.
E' importante però che non si perda il focus su ciò che stiamo cercando di capire.
Se non hai dato una scorsa allo status di questa piccolo enigma nel Forum suddetto cerco di 
sintetizzarti il punto focale per non disperdere le (preziose) energie in direzioni multiple e non 
coese.
1) Sul fatto che lato server possiamo distribuire selettivamente i file compressi on-the-fly (usando 
per es.mod_gzip) solo ai browser che dichiarano una 'accept-encoding:gzip' non ci sono dubbi, è 
quello che si fa usualmente e non è questo il focus.  
2) Ciò che stiamo cercando di capire è come mai , dati un header di richiesta del browser di un file 
.htm.gz e un header di risposta del server Apache con direttiva 'AddEncoding gzip .gz' attivata (e 
si presta perfettamente a questo scopo il server gratuito di Digiland, sul quale ovviamente non 
possiamo mettere le mani) si ottenga una matrice di risultati(chi visualizza e chi scarica) 
assolutamente non correlabile ad uno specifico browser o OS.
Personalmente mi trovo nelle tue identiche condizioni: sul mio sistema WIN95 con modem56K  
l'apertura automatica dei file .gz avviene sempre, come mi aspetto, con qualunque browser in 
circolazione (NS4.06+,IE4+,Opera5+,Mozilla) in quanto tutti browser win citati supportano da tempo 
il 'content-encoding'.
Paradossalmente questa condizione di 'privilegio' mi impedisce di aggredire il problema che affligge 
una parte degli utenti che si vedono invece richiedere la dialogbox, non potendolo riprodurre.
Ciò che posso fare è limitarmi a usare un packetsniffer per verificare se tutto va come mi aspetto 
ed è esattamente ciò che succede, il log che segue(richiesta e risposta) è relativo ad IE ma è 
coerente con tutti gli altri browser citati. 
---------------------------------
WIN95 IE5.01   perl.htm.gz
GET /armageddon99/perl/perl.htm.gz HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, 
application/msword, application/vnd.ms-powerpoint, application/pdf, */*
Accept-Language: it
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows 95)
Host: 
digilander.iol.it
Connection: Keep-Alive
Cookie: Apache=23.15.123.184.174741012322747696;
HTTP/1.1 200 OK
Date: Tue, 04 Jun 2002 14:49:39 GMT
Server: Apache/1.3.12 (Unix)
Last-Modified: Fri, 31 May 2002 14:29:03 GMT
ETag: "1962e6c-1a9ce-3cf788af"
Accept-Ranges: bytes
Content-Length: 109006
Keep-Alive: timeout=15, max=300
Connection: Keep-Alive
Content-Type: text/html
Content-Encoding: gzip
------------------------------------------------------------------------
3) Relativamente al nome del file usato dal browser oggetto del tuo secondo intervento,forzato con 
la direttiva 'content-disposition:inline' non è rilevante ai fini della nostra analisi in quanto se 
tutto funziona a dovere in automatico come succede ad una buona parte degli utenti, non ha 
importanza quale nome del file verrà attribuito dal browser in cache, tutto deve essere trasparente 
all'utente, la cosa essenziale è che il file html venga visualizzato automaticamente come un 
normalissimo file html in chiaro.
Il server Apache, come puoi vedere dagli headers risponde come atteso con le due direttive chiave 
content-encoding e content-type fornendo le informazioni rilevanti al browser. Non serve null'altro 
per funzionare e sui nostri sistemi ciò avviene correttamente.
4) La magagna, come tu giustamente ipotizzi potrebbe anche essere nel'header di risposta degli 
utenti che ottengono un comportamento imprevisto. Ma ciò dovrebbe significare che 'qualcuno' filtri 
l'header di richiesta del browser oppure l'header di risposta del server, eliminando per esempio la 
direttiva 'content-encoding'.
Oppure, e il tuo intervento suggerisce intelligentemente anche questa possibilità, potrebbe essere 
addirittura introdotta da queste entità intermedie (LAN,proxy,firewalls.ecc..) una arbitraria 
'content-disposition:attachment' che forzerebbe su molti browser l'apertura della dialogbox.
5) Per scartare quest'ultima ipotesi (che io spero non si verifichi) basterebbe monitorare con un 
packetsniffer(tipo CommView) gli headers di un browser con comportamento 'non conforme'. Se gli 
headers risultassero coerenti con quelli che ti ho postato potremmo focalizzarci sul client ed 
escludere la negoziazione http dall'indagine.
Purtroppo ancora nessuno ha postato tali headers per scartare questa ipotesi e personalmente 
purtroppo non riesco a trovare un PC con comportamento 'inatteso' per cui la mia area di intervento 
può essere solo dialettica.
6)L'obiettivo, dati i presupposti che spero di aver chiarito sufficientemente e che puoi integrare 
con il thread contenuto nel forum HTML(
www.html.it
) punta ora ad individuare almeno 1 caso in cui 
sia chiaro il motivo del malfunzionamento.
Per quanto riguarda wget 1.7.1 il comportamento è coerente con quanto atteso, il link postato ci 
serve esclusivamente come banco di test comune, naturalmente non può essere integrato in una pagina 
html così com'è perchè escluderebbe tutti i browser che non supportano il content-encoding(ma questo 
fa parte di un passaggio successivo).
Spero di aver chiarito anche agli altri che vorranno contribuire a risolvere questo 'quesito con la 
Susy' , inutile dirvi che una volta risolto questo, lato client si aprirebbero delle prospettive 
molto interessanti.
Ciao!!!
armageddon99

Per quanto ne so io l'argomento di cui si sta parlando fa capo a diversi
problemi e/o concetti:
 1)Il fatto che durante il download di un file di x byte da internet, puo
variare in base al tipo di file. Ora vi spiego, il protocollo v34 o v90,
dipende dal vostro modem, hanno di per loro un fattore di compressione del
dato che trasferiscono. Nel caso voi scarichiate un file di testo e'
possibile che venga giu ad una velocita superiore a quella di targa del
vostro modem, potete farvi un'idea se usate winNT o 2000, durante il
download potete arivare anche ad 11kbyte al secondo con un modem
33,6(Kbit).Invece se scaricate un file compresso es. .zip o .gz il flusso
e' gia compresso e non vi e' nessun vantaggio.
2) Nel caso specifico di cui parli esistono estensioni a DOC per i
webserver, ad esempio mod_gzip per apache, che permettono di comprimere al
volo in formato gzip .gz qualsiasi flusso di dati che esce dal server.
Quindi nel caso io avessi su una macchina configurata con mod_gzip e
chiedessi la pagina 
http://server/index.html
 automaticamente verrebbe
inviata al browser compressa con ovvi vantaggi in risparmio di banda e non
dovrebbe incontrare i problemi che avete fino ad ora riportato ad esempio
la finestra di salvataggio file che compare automaticamente.
2.a) ovvio che se chiedete 
http://server/pagine.zip
 non vi sara alcun
guadagno durante la compressione anzi si sovraccaricherebbe il server.
Spero di essere stato chiaro ed esauriente,
by Pinuc.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Pinuc, grazie dell'intervento, l'enigma non è ancora stato risolto. Coiò che affermi al punto 1 è 
vero, il modem riesce a comprimere di per sè di circa un fattore 2:1 i file di testo (html,js,css) 
mentre chiaramente non aiuta negli altri casi.  Questo spiega perchè quando scarichiamo un file .gz 
5 volte più piccolo dell'originale come nel test che stiamo facendo, i tempi di download non 
diventano 1/5 ma circa si dimezzano (il chè non è malvagio comunque...).
Dovresti leggerti bene i thread per capire il punto nodale della faccenda: devi provare a cliccare 
sul link, se il browser ti chiede di scaricare manualmente il file, forse puoi aiutarci a risolvere 
il mistero postando l'header HTTP che ti arriva sul PC.
Ciao!
armageddon99
 
 

 cerchero` un'altra donna dentro ai sogni di Tarzan
Ciao, credo che Juliet si riferisse al fatto che probabilmente wget non invia la direttiva 'accept-
encoding' nell'intestazione HTTP.  Se la invia dovrebbe aprirti il file compresso automaticamente, 
se non la invia dovrebbe trattarti il file .gz come un qualunque zip , per cui dipende da come hai 
settato il browser.
Al di là di questo, sapere se con i browser windows a te il documento del link si apre 
automaticamente  può fornirci dei dati in più.
grazie!
armageddon

 una stupidissima riga in httpd.conf
Su questo non ci sono dubbi, è tutto già noto, il focus è un altro, prova a rileggerti i thread 
precedenti per capire di cosa stiamo parlando.
Scusami, non posso rifocalizzare il problema ogni volta.
Grazie comunque.
ciao
armageddon

 cerchero` un'altra donna dentro ai sogni di Tarzan
Questa è giustamente una ipotesi di lavoro, ma pare che anche se elimini tutte le associazioni con 
l'estensione .gz nel registro di Windows il caso anomalo si ripresenti comunque su alcuni PC ed è 
questo che non si spiega ancora.
Ti dirò di più , ho cercato di riprodurre la richiesta di download dei browser sulla mia macchina 
associando esplicitamente il file .gz a WINZIP ma come mi aspettavo tutti i browser WIN 
Ie,Mozilla,Opera,Netscape continuano a gestire automaticamente il file .gz perchè il server manda 
loro la 'content-encoding' corretta.  Il file .gz per il browser diventa un file da trattare in 
maniera speciale e quindi le applicazioni helper non intervengono.
Una delle ipotesi più probabili consiste nella possibilità che su certi PC non arrivi affatto il 
'content-encoding' dal server digiland e per verificarlo occorre qualcuno che abbia un packet-
sniffer sul proprio PC, e posti i due header (request and answer) come ho fatto in un post 
precedente, potrebbe essere una stupidata risolvibile con una banale impostazione lato client come 
potrebbe essere anche un problema non accessibile( se qualche proxy si mangia dei pezzi di 
header...).
Il tema non è triviale come può sembrare, personalmente riesco ad aprire automaticamente i file 
compressi .gz , l'interesse è di carattere più generale, non personale.
Grazie!
armageddon