Decodifica corpi di risposta gzip-ed con url-retrieve

Question

Per un'estensione Emacs, mi piacerebbe recuperare i dati su HTTP. Non mi piace particolarmente l'idea di eseguire il bombardamento su cose come wget, curl o w3m per poterlo fare, quindi sto utilizzando la funzione url-retrieve.

Uno dei server HTTP con cui sto parlando ignora le intestazioni Accept-Encoding e insiste per inviare sempre i suoi dati con Content-Encoding: gzip.

Di conseguenza, e del fatto che url-retrieve non decodifica automaticamente i corpi di risposta, il buffer url-retrieve mi presenterà conterrà dati gzip binari.

Sto cercando un modo per decodificare il corpo della risposta, preferibilmente pezzo per pezzo, man mano che i dati arrivano. C'è un modo per ordinare a url-retrieve di fare questo per me?

Decodificare la risposta tutto in una volta, una volta che è arrivato completamente, sarebbe anche accettabile, ma preferirei evitare tutto il fubar coinvolto nella creazione di un sottoprocesso asincrono che esegue gzip, piping le parti della risposta che ho ottenuto, e leggendo di nuovo i pezzi decodificati, cercherò qualche funzione di libreria qui.

Answer 1

Quello che auto-compression-mode esegue gzip sul file non compresso. Vedi ad esempio jka-compr-insert-file-contents in jka-compr.el. Quindi, se hai intenzione di usare auto-compression-mode per fare la decompressione, dovrai prima scrivere la risposta a un file. Per esempio, qualcosa di simile:

(defun uncompress-callback (status) 
    (let ((filename (make-temp-file "download" nil ".gz"))) 
    (search-forward "\n\n")    ; Skip response headers. 
    (write-region (point) (point-max) filename) 
    (with-auto-compression-mode 
     (find-file filename)))) 

(url-retrieve "http://packages.ubuntu.com/hardy/allpackages?format=txt.gz" 
       #'uncompress-callback) 

(. Se non si desidera creare un file temporaneo, si dovrà fare la propria gestione sottoprocesso, ma non è così difficile come si implica nella domanda)