On Fri, Jan 8, 2016 at 3:27 AM, Yann Ylavic <[email protected]> wrote:
> > On Fri, Jan 8, 2016 at 8:49 AM, Jan Kaluža <[email protected]> wrote: > > > > Content-Type: application/x-tar > > Content-Encoding: x-gzip > > > > So, the mod_mime_magic is saying here that the body is tarball encoded by > > gzip. > > AIUI, mod_mime_magic does indeed try to uncompress the tar.gz and adds > the above headers. > Well, not strictly true, mod_deflate uncompresses it ;-) > But I think even we are right here, the Content-Encoding should be used > only > > when httpd itself encodes the original content, otherwise it confuses > > clients (I've asked few people and it confuses some web browsers too - I > can > > get more info if needed.). > > Agreed, this looks wrong, the browsers will likely use the .tar file > instead (this adds unnecessary cycles to both the server and client). > I've observed this on many clients downloading .tar.gz and storing the file as the decompressed .tar when I had configured .gz to report Content-Encoding: x-gzip, and this is simply using mod_mime configuration directives. But that was shooting myself in the foot, had not stopped to consider what mod_mime_magic might do. > Maybe we could stop setting Content-Encoding in mod_mime_magic and just > use > > Content-Type? > > Since it's always been there, we probably should add a new > mod_mime_magic directive to control the behaviour and avoid breaking > cases. > Agreed it is configuration, but cant we simply tweak our recommended conf/magic file??? # standard unix compress # Enable the alternate line below to present gzip content as a transfer encoded # stream of the underlying content; #0 string \037\235 application/octet-stream x-compress 0 string \037\235 application/octet-stream # gzip (GNU zip, not to be confused with [Info-ZIP/PKWARE] zip archiver) # Enable the alternate line below to present gzip content as a transfer encoded # stream of the underlying content; #0 string \037\213 application/octet-stream x-gzip 0 string \037\213 application/octet-stream WDYT? > Something along: > > Index: modules/metadata/mod_mime_magic.c > =================================================================== > --- modules/metadata/mod_mime_magic.c (revision 1723283) > +++ modules/metadata/mod_mime_magic.c (working copy) > @@ -456,6 +456,7 @@ typedef struct { > const char *magicfile; /* where magic be found */ > struct magic *magic; /* head of magic config list */ > struct magic *last; > + int uncompress; > } magic_server_config_rec; > > /* per-request info */ > @@ -511,6 +512,10 @@ static const command_rec mime_magic_cmds[] = > { > AP_INIT_TAKE1("MimeMagicFile", set_magicfile, NULL, RSRC_CONF, > "Path to MIME Magic file (in file(1) format)"), > + AP_INIT_FLAG("MimeMagicUncompress", ap_set_flag_slot, > + (void *)APR_OFFSETOF(magic_server_config_rec, uncompress), RSRC_CONF, > + "Whether MIME should try to render uncompressed content by > recognizing " > + "the underlying type, or not (default)"), > {NULL} > }; > > @@ -2081,6 +2086,9 @@ static int ncompr = sizeof(compr) / sizeof(compr[0 > > static int zmagic(request_rec *r, unsigned char *buf, apr_size_t nbytes) > { > + magic_server_config_rec *conf = (magic_server_config_rec *) > + ap_get_module_config(r->server->module_config, > + &mime_magic_module); > unsigned char *newbuf; > int newsize; > int i; > @@ -2095,15 +2103,20 @@ static int zmagic(request_rec *r, unsigned char *b > if (i == ncompr) > return 0; > > - if ((newsize = uncompress(r, i, &newbuf, HOWMANY)) > 0) { > - /* set encoding type in the request record */ > - r->content_encoding = compr[i].encoding; > - > + if (!conf->uncompress) { > + magic_rsl_puts(r, apr_pstrcat(r->pool, "application/", > + compr[i].encoding, NULL)); > + } > + else if ((newsize = uncompress(r, i, &newbuf, HOWMANY)) > 0) { > newbuf[newsize-1] = '\0'; /* null-terminate uncompressed data */ > /* Try to detect the content type of the uncompressed data */ > if (tryit(r, newbuf, newsize, 0) != OK) { > + magic_rsl_puts(r, apr_pstrcat(r->pool, "application/", > + compr[i].encoding, NULL)); > return 0; > } > + /* set encoding type in the request record */ > + r->content_encoding = compr[i].encoding; > } > return 1; > } > Just trying to understand why conf/magic can't be the lever for this behavior. Are you trying to trip this behavior on a per-file/per-directory basis? That would be one case where keeping two entire conf/magic[12] files loaded would seem excessive. What about adding a MimeMagicItem directive to add/modify just a few lines not in the master mime magic file table?
