[Mailman3-dev] URLs on Mailman web GUI and archive pages
r.barrett at openinfo.co.uk
Thu Mar 25 06:15:38 EST 2004
The URLs generated on web pages, both static and dynamically generated
pages, by Mailman 2.1.x code are a mixture of absolute and relative
My view is that, during the the Mailman 3 development, the code
generating such URLs should all be such that all URLs are generated as
page relative URLs.
The URL generation arrangements should also support the ability to
configure the addressing scheme used for MM's web GUI in a more
flexible way; for instance:
a. the ability to use http for public/authenticated access but https
for restricted/authenticated access.
b. the ability to use http for some lists but https for other lists
The page relative URL generation suggested above should also simplify
achieving the addressing scheme objectives.
The present URLs are a problem for a number of reasons:
1. using a mixture of addressing schemes would assist with the problem
cited by one of my correspondents:
> On Wed, 24 Mar 2004, Richard Barrett wrote:
> : You pretty much have to decide to use https for the whole web
> : interface, both admin and list user, but I do not see that as a
> : with SSL capable browsers being the norm these days.
> The problem is that on a server which hosts multiple virtual domains,
> can either (a) buy a cert for every virtual hostname (expensive) or (2)
> use a self-signed cert and let people click-thru the certificate
> warning. I find that the less technically-inclined users are thrown
> into a
> tizzy when they see the certificate mismatch warning - they are totally
> unsure whether or not it is safe to proceed.
> These are the kinds of admin issues that programmers often don't think
> about. ;)
2. allowing access to a Mailman servers through a transparent,
reverse-proxying server is infeasible unless a rewriting HTML filter is
applied to the pages returned to it by the Mailman server. This
situation creates the requirement for MM to exclusively generate page
relative URLs; server relative URLs still make a rewriting HTML filter
3. links in archived mail to attachments extracted by the present
pipermail archiver are currently generated as server relative given the
present state of the list privacy. This means that changing a list's
archive privacy status leaves links to attachments broken unless
bin/arch is used to rebuild the entire list archive. Whichever archiver
is packaged with MM3 should avoid this problem.
Richard Barrett http://www.openinfo.co.uk
More information about the Mailman3-Dev