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

[Barry Warsaw]

On Thu, 2004-03-25 at 06:15, Richard Barrett wrote:
> 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.

In general, I agree.  MM2's page generation system never did this
consistently or correctly, so I found that switching to an absolute url
scheme was the only way to get it to work most (more?) of the time.

> 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:

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

These are all excellent use cases.  Can you add them to the MM3 wiki so
they don't get lost?

-Barry