Re: [groff] infinite loop with groff + mom

[Ralph Corderoy]

Hi Peter,

> > Your Apache is sending a Content-Encoding header and the browser is
> > decompressing the result.
>
> Not much I can do about that, unfortunately.  The Apache server is
> iPage's, where the mom site is hosted.

It seems they let you tinker with the .htaccess in some clunky fashion.
http://ipagehosting.co.uk/knowledgebase/beta/article.bml?ArticleID=631

curl without --compressed doesn't send a `Accept-Encoding: deflate,
gzip' header, but despite this that Apache is sending back a
Content-Encoding that's gzip.  curl ignores it, and a .tar.gz results on
disk.  Give curl --compressed and it sends the A-E header, Apache sends
the C-E as before, that's declaring the bytes on the wire to be
compressed, curl, rightly, decompresses them, and a .tar ends up on
disk, called .tar.gz.  Apache is wrong.

Apache has been wrong for many years in many ways in this area;  I'm
chatting about this in my IRC logs at least as far back as 2010.  For
example, Firefox and Chrome have code to explicitly ignore some
combinations of headers from Apache that claim the wire bytes are
*double* gzip'd.

https://kevinlocke.name/bits/2016/01/20/serving-pre-compressed-files-with-apache-multiviews/
covers some solutions, explicitly mentioning .tar.gz, and they may give
a lead what to do without using Multiviews.

> Equally, the Opera browser, which retrieved and decompressed the
> tarball for Ulrich, has no facility that I know of for altering this
> behaviour

Nor should it have;  it's following the RFC and is in the right.
Firefox and Chrome choose to pander to Apache's, or its common
configuration's, brain-damage.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy