[dokuwiki] AW: Re: http-decompression screws up plugin installation

At my installation, gzinflate() does fail in that case - causing an error 500.
SendRequest() should better have an '@' before gzinflate().
 
Yes, am making up a feature request for content-depending handling of files in 
plugin-manager.

--- Andreas Gohr <andi@xxxxxxxxxxxxxx> schrieb am Do, 28.5.2009:


Von: Andreas Gohr <andi@xxxxxxxxxxxxxx>
Betreff: [dokuwiki] Re: http-decompression screws up plugin installation
An: dokuwiki@xxxxxxxxxxxxx
Datum: Donnerstag, 28. Mai 2009, 15:40


On Thu, May 28, 2009 at 3:31 PM, Marcel <sonnebln@xxxxxxxx> wrote:
> I tried installing the pdfex plugin from
> http://www.wernerflamme.net/data/pdfex.tar.gz.
> This resulted in an error in HTTPClient->sendRequest() at gzinflate()
>
> Is this a problem with the wernerflamme.net server, with the HTTPClient or
> my installation?

This seems like a problem with the server:

Date: Thu, 28 May 2009 13:35:24 GMT
Server: Apache/2.0.54 (Debian GNU/Linux) mod_ssl/2.0.54 OpenSSL/0.9.7e
Last-Modified: Wed, 20 Jun 2007 15:41:55 GMT
ETag: "d11713-101a-4505f6c0"
Accept-Ranges: bytes
Content-Length: 4122
Content-Type: application/x-tar
Content-Encoding: x-gzip


The problem is the Content-Encoding header which says that the content
is transferred gzipped. HTTPClient will unpack that correctly. The
real problem arises in the plugin manager which uses the filename to
determine how to unpack the file. Since it still end in .gz it will
try to decompress it (again) which will fail.

That the server is serving this file with a Content-Encoding is wrong
IMHO, but I guess it would be a good idea to make the plugin manager
no longer depend on the file extension but use some heuristics to
determine the file type instead. Could you please open a feature
request?

Andi


-- 
splitbrain.org
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: