[Mailman-Developers] possible bug in b5

Ken Manheimer klm@python.org
Sun, 18 Oct 1998 13:59:11 -0400 (EDT)


On Fri, 16 Oct 1998, The Dragon De Monsyne wrote:

> On Fri, 16 Oct 1998, Corbett J. Klempay wrote:
> 
> > I'm not sure if this is known/already fixed or what...
> > 
> > I created a list for another guy...and he never went in to put in the
> > stuff like the list description and all...I think he went into the admin
> > section once to mass subscribe a few people and that was it...
> > 
> > When we went to the main listinfo page, the new list was not listed, even
> > though it was a public list.  I went to the General Options page and
> > edited the preferred hostname field and hit submit.  After doing this, the
> > new list was listed on the main public list page (with a blank short
> > description, as I still haven't touched any of the other General Options
> > fields).  
> 
> > 
> > Anyone else seen this before?  It's not a biggie; and it's now fixed
> > here...
> 
> 	Yup. this is mailman's virtual hosting 'feature'. I posted a patch
> fer this earlier.  Basically if there is a http 1.1  'HTTP_HOST' value,
> mailman tries to only show the lists whose preferred host match that
> value. IMHO, however the current implementation of mailman goes about this
> wrong. It looks at the   preferred hostname for the hostname to match.
> However the prefered hostname is generally the hostname that goes on
> outgoing _email_. The hostname for email and for WWW may not always be the
> same (in my case it isn't) The patch I submitted makes it check against
> the hostname part of the base mailman URL, instead.  Lastly I _strongly_
> think this feature should be en/disenable-able  via a switch in mm_cfg
> (defaulting to disabled), as it is extremely confusing. 
> (you aren't the first to report it as a bug)

You're right, the web_page_url should have been used in the first place,
and i've fixed that in the current sources.  Sorry it's taken me so
long to correct it.  I've also created a system default value,
VIRTUAL_HOST_OVERVIEW, which controls whether or not the constrain is in
effect - i have made it on by default, but am open to dissuasion on
that.  At the least, we'll need to warn people who depend on it of the
change, if we make it default to off.

(About the behavior in general - i'm sure that the effect of the option
is very surprising, if you don't know about it, but i expect that it's
not so complicated as to be confusing, _as long as you are aware of the
cause_.  And i do think it's very important for sites that are hosting
different domains on single hosts, and wanting to keep the domains
effectively separate - i would suppose it is crucial for ISPs that are
renting out domains, for instance.) 

ken manheimer
klm@python.org