From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN:  
X-Spam-Status: No, score=-4.2 required=3.0 tests=ALL_TRUSTED,BAYES_00,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,
	T_SCC_BODY_TEXT_LINE shortcircuit=no autolearn=ham autolearn_force=no
	version=3.4.2
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
	by dcvr.yhbt.net (Postfix) with ESMTP id 67CAE1F54E;
	Sun, 21 Aug 2022 22:11:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=80x24.org;
	s=selector1; t=1661119903;
	bh=oMIGPHePeyKK+yUCpjLU1QQH9M/zKyGxrQS4KoNg3nU=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=0qrqEO2WIXf4aQFNBcNjCYsFANjF8KTYkW+/W8ImQa5mSN0reGrrB9ohn4V5ANf9V
	 2CgkU5pLq8FaHcH5NQGiXo75BHXgyReAySwBs5kaQXkVbtRSDZ0C+iRbJ5yzL5JWbO
	 LYK8PpnhSYGhc3fCSCy+LcMimGDcGE/4jF1kdwx4=
Date: Sun, 21 Aug 2022 22:11:43 +0000
From: Eric Wong <e@80x24.org>
To: Mark Wielaard <mark@klomp.org>
Cc: overseers@sourceware.org, meta@public-inbox.org
Subject: Re: Using plus (+) in list name
Message-ID: <20220821221143.M305678@dcvr>
References: <YwKPUv5IbIOYt2SO@wildebeest.org>
 <20220821205338.M316466@dcvr>
 <YwKnFCvganW7ErXU@wildebeest.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <YwKnFCvganW7ErXU@wildebeest.org>
List-Id: <meta.public-inbox.org>

Mark Wielaard <mark@klomp.org> wrote:
> On Sun, Aug 21, 2022 at 08:53:38PM +0000, Eric Wong via Overseers wrote:
> > Mark Wielaard <mark@klomp.org> wrote:
> > Interesting that NNTP and IMAP work (I wasn't expecting it :x).
> > 
> > I can't remember off the top of my head, but is '+' allowed by
> > the relevant NNTP and List-Id RFCs?
> 
> I don't know. I just observed that I can see the group name
> inbox.gcc.libstdc++ in my nttp and imap readers when pointing at
> inbox.sourceware.org.

I suppose it's OK as long as real-world clients are happy.

> > +++ b/lib/PublicInbox/WWW.pm
> > @@ -23,7 +23,7 @@ use PublicInbox::WwwStatic qw(r path_info_raw);
> >  use PublicInbox::Eml;
> >  
> >  # TODO: consider a routing tree now that we have more endpoints:
> > -our $INBOX_RE = qr!\A/([\w\-][\w\.\-]*)!;
> > +our $INBOX_RE = qr!\A/([\w\-][\w\.\-\+]*)!;
> >  our $MID_RE = qr!([^/]+)!;
> >  our $END_RE = qr!(T/|t/|t\.mbox(?:\.gz)?|t\.atom|raw|)!;
> >  our $ATTACH_RE = qr!([0-9][0-9\.]*)-($PublicInbox::Hval::FN)!;
> 
> That works! https://inbox.sourceware.org/libstdc++ looks fully
> functional now.

Good to know.  I'll make a patch ASAP and maybe some tests
down-the-line...

> Now to figure out how to properly include that patch before the other
> sourceware overseers figure out I patched the packaged code in place.

If you're using a .psgi config file to customize the middleware
layer, you should be able to access `our' vars through it:

diff --git a/examples/public-inbox.psgi b/examples/public-inbox.psgi
index e017b2fb..36cd8b57 100644
--- a/examples/public-inbox.psgi
+++ b/examples/public-inbox.psgi
@@ -14,6 +14,7 @@ use strict;
 use warnings;
 use PublicInbox::WWW;
 use Plack::Builder;
+$PublicInbox::WWW::INBOX_RE = qr!\A/([\w\-][\w\.\-\+]*)!;
 my $www = PublicInbox::WWW->new;
 $www->preload;
 
There's a bunch of `our' vars which happens to be accessible across
namespaces, some with the intent of being tweaked by end users,
some for internal-use only.

I can't remember what reasoning I had for making $INBOX_RE
globally-accessible, but I'm fine with it used in this way.