From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dcvr.yhbt.net (dcvr.yhbt.net [173.255.242.215]) by sourceware.org (Postfix) with ESMTPS id 3D3D23858C83 for ; Sun, 21 Aug 2022 22:11:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3D3D23858C83 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) Date: Sun, 21 Aug 2022 22:11:43 +0000 From: Eric Wong To: Mark Wielaard Cc: overseers@sourceware.org, meta@public-inbox.org Subject: Re: Using plus (+) in list name Message-ID: <20220821221143.M305678@dcvr> References: <20220821205338.M316466@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: overseers@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Overseers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2022 22:11:45 -0000 Mark Wielaard wrote: > On Sun, Aug 21, 2022 at 08:53:38PM +0000, Eric Wong via Overseers wrote: > > Mark Wielaard 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.