[Mailman3-dev] URLs on Mailman web GUI and archive pages

[Richard Barrett]

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 
URLs.

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:

<quote>
> 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 
> problem
> : with SSL capable browsers being the norm these days.
>
> The problem is that on a server which hosts multiple virtual domains, 
> you
> 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 
> mismatch
> 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. ;)
</quote>

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 
necessary.

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