Compressed HTML, Apache MultiViews for /doc/, new doc-base option ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
X-Archive-Search-Keywords: apache doc-base compress gzip multiviews doc-base apache boa dhttpd dhelp dwww policy
I've been hard at work on a new-fangled packaging setup for the
XEmacs-21.2-Beta, and have created a `doc-html' package for it, using
`texi2html'. I would really like to compress all of those HTML
files, as well as the rest of the HTML in /usr/doc, just to save
space. It can make a huge difference on a small laptop, freeing
precious hard disk space for several CVS checkouts, for instance.
I've learned that with Apache, you can set the "MultiViews" option,
and it will serve the "<document>.html.gz" when the "<document>.html"
is not found. I notice that by default, our Apache does not have the
"MultiViews" option enabled in "/doc/". I think that it should.
Presumably, the other HTTP daemons can be modified to behave in a
similar fashion, if they don't already deal with this.
I'm less concerned about whether the data is uncompressed prior to
service or sent with an "application/x-gzip" content-encoding than I
am with that it will find "<document>.html.gz" when "<document>.html"
is requested but doesn't exist anymore. (Of course, if it sends gzip
encoded data, it needs to report that to the browser...) We should
*not* have to stream-edit outgoing HTML to fix up the links inside
it. It would be nice to make it so that if a browser cannot accept
gzip encoded content, the document is uncompressed prior to service,
and if it does, it's sent compressed. Johnie? Does Apache deal with
that?
I would like `doc-base' to be modified[1] so that, at local option,
all HTML documentation gets compressed after installation. I have
written some preliminary code to handle that. I would like folks who
understand `dpkg' well to look it over and see if it's correctly
implemented, and if so, we can roll it into `doc-base' somehow.
Please don't try this on a production system, etc. etc... and RTFS
before you run it. I've not looked at it in 5 or 6 months. I think
it used to work...
Mainly, I want folks to look at it and see if they like the idea.
Should I pursue this? Would yous like that?
http://bittersweet.inetarena.com/cgi-bin/viewcvs.cgi/doczipper/
CVSROOT=:pserver:anoncvs@bittersweet.inetarena.com:/var/cvs/debian
Blank password, module "doczipper".
It edits the "/var/lib/dpkg/info/<package>.list" databases so that
when a package is removed, purged, or upgraded the renamed HTML
documents are properly tracked and dealt with.
Footnotes:
[1] I'm willing to take on this task.
- --
We should not penalize the conscientious to coddle those who run brain-dead software.
I am karlheg, of deB.ORG. You will be freed. Resistance is useful.
mailto:karlheg@debian.org (Karl M. Hegbloom)
http://www.debian.org/~karlheg
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
mQGiBDd9FHERBACPLkybc3h39HQyzCEYtljMnrOjDg1KY2BXDwC4vC4m6zQ4w2Kr
72YEZ4+rwGa6lluPpf+cmeRYAHvxO0sgRysWD1qyer0+wash7y9G/QG6+XIWlZ45
X11EduAr9G5n99SjaK67a6vqe9rplZrJgp0TrkKXrZo46Plyr4OVIo588wCgnc6r
a8K6fxVfUc2iqxvL8pYK+z0D/04ZN10kC2W1mxMdvbNBT+aB/jMFu9GsnP5kJJSu
n7IqNUMHQVylIxUeKeNO0FlKJ4tE0ZWXi1CFV02+BdW9sSzevbP45TgzPXwkehK5
XXaKrWBS3eZOTJ5Z23qBaM9VmuFywSN7t6ptKld6MjaKCvbVE57vVT1is5gIuR4C
qhgvA/4z2xrYq7tB5FHAnupoHHWotFKvI+8rsRIvme9l7h7YMEvH7EJEYwtkZD8a
Z2bAr52Oe/NShkRtj0XuGqStJ6ifu0TCSs/wKzNqmXfH8xCYqjeOQ/rC8QqyevvD
dxC6UGt3YwAoNqKD7AKnNr188VGNyPhhYyiu4gvYeESK3mG+l7QlS2FybCBNLiBI
ZWdibG9vbSA8a2FybGhlZ0BkZWJpYW4ub3JnPohVBBMRAgAVBQI3fRRxAwsKAwMV
AwIDFgIBAheAAAoJELSFmU7xzGp6ghgAmgLuY5rkZ6J42nvp1QOpklB4hyUvAJ0b
aAusbYsyfYh1Wb+2oiozBap1Q4kBFQIFEDi11CSMRdyqIb5RyQEBKccH/i1oMjpX
ITgU1cnJTGUh68uWyaiOGyzbEykveHX/Z5UpuaCc+i7jefT8fyXbWluWZ5C+teJI
kpHM7Z8fGgqWSe5hWbLBz7zkP/+9Ii9aOv4e/rvh/9OTnAUmgUgJjMIziUob2dGY
cvVKBSQma1caqBDSwoZuPDSFnhkkxnn+q3l1zvTl/VPoVIHXCtxYG/4x8y1oYZ5S
pJg+qIm5eikVXKJjhEj8izsVJBJbI0yONOUa+fOCUIc1e0MPy8Ant3TGPbR8FbMG
TapnKEUtppN3XmOtkLOeq5YHQHE95nCU9bR/+HGRy2Dm1kN4jk8QCaJV0Sf+OK20
LVUmsWEKAaUrjuq0O0thcmwgTS4gSGVnYmxvb20gKEhvbWUpIDxrYXJsaGVnQGJp
dHRlcnN3ZWV0LmluZXRhcmVuYS5jb20+iFYEExECABYFAjh+7DYECwoEAwMVAwID
FgIBAheAAAoJELSFmU7xzGp6iccAn1iKWD278Y3tMK3IjD5CcPtTf38cAJ424aOf
Sa3C0fYYXMN7cK9mXF7VB4kBFQIFEDi11FKMRdyqIb5RyQEBFRAH/3LmrMjIQafO
w6fc+wWLhHCxpJPQuxh6CGjWr79Eg3lt4Yo7VYsY6VoxHoGi230f+jcLqRN6sMce
HxBgTYjc+Ap8Quud0LRTC91jjI7nt6rpA/2hnqAmZyyK9MfMaZzvFDQMZwtrskbk
8tcy7Qtqh0iOMUvLdVDI4wogoCih6wJr127Vmr6A8FHIR9iLisQArl7TKb4hNUXg
y4blNY3iJsl0LI2Mb7Jd5j1E++vt4O6KMNTpNu5R84DWgzt1uE97aGWVwG/rtLYH
dJ/woR1PZruAH8ce8ZuItkZQMZmO86ip2sjGn4JJVUQCZ94qK/km2g0HmbNAn74h
1hxEgOk1Qba5AQ0EN30UixAEAP/qZtKCaMmIONxOL1bxQvVNjEWav6stWDkpkVTa
uFUsHZvfSWXrNqhho5/Keo1teJ+aEpGqUTPs2wx0qM+8pzlCsF+UFHfpdfHwOFJ+
vifRhUhPaAu0d+y86S5AIp1L0kwGzFBlbUlcRFvn7NGi5tVHnTI+1RHIGsXgn63r
D9SfAAMFBAD/cYqwCb/MvcDQ76w58GojpV6gLGIw4lGycXzNtClL0nnHNMzEBfjn
Bxi4bLbMqwR/zEqpVvsJ7xF3M76FKAQ0ei/MqH23A9Efq96jdCJzgokClguqFf2I
9CovPykO9uMFSx5kRixmHBbHYW7A/jx0pBbCY03QqmxuB8DlRC76VYhGBBgRAgAG
BQI3fRSLAAoJELSFmU7xzGp6HUEAn1Dx5JDYbODrBylp4MUeKms7QMGCAKCUSayA
ISRR3LeGUdQoWQcwKir44w==
=u/HR
- -----END PGP PUBLIC KEY BLOCK-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
iD8DBQE5+iLBtIWZTvHManoRAqKoAJ9Doe1l5+Gm/yquESm6yUvZrH/KdwCdEQux
aawlRjQtkqpqWS8nTWWTk7s=
=jEPy
-----END PGP SIGNATURE-----
Reply to: