Re: Occasional web view corruption (extra html escapes)

[Eric Wong <e@80x24.org>]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Tue, Sep 03, 2024 at 07:11:51PM GMT, Eric Wong wrote:
> > Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> > > In the HTML source, I see:
> > > 
> > > 	<a
> > > 	href="?t=20240829184845"></a>From<a
> > 
> > By any chance, do you have empty `address =' entries in the
> > public-inbox config file?
>
> Doesn't appear to be the case. The config is:
> 
>     [include]
>       path = /etc/public-inbox/config.include
>     [publicinbox "tools"]
>       address = tools@linux.kernel.org
>       url = tools
>       inboxdir = /srv/public-inbox/lore.kernel.org/tools
>       indexlevel = basic
>       newsgroup = org.kernel.linux.tools
>       boost = 10
>       listid = tools.linux.kernel.org
>     (repeat for every list)

OK, and nothing malformed or commented out in the address=
fields?  And no stray semi-colons or hash marks in any address
fields which comment out only the value?

Because having an empty address= and empty url= field in my
publicinbox.lkml section gives me something close (but not
exactly) to what you have:

<a
href="/?t=20240829184845"></a> &<a
href="/?t=20240829184845"></a>lt<a
href="/?t=20240829184845"></a>;<a

Note the href has a leading slash in my near-reproduction
but yours did not.

It's not a double-escaping problem, but the substituion is
is breaking already -escaped `&lt;' and `&gt;' apart with <a>
tags in between characters.  but I'm not sure how this is
happening to you if all your address fields look OK.

I'll filter out blank addresses in our config reader, but
I also wonder if there's anything else going on...

And all your writes to the config are via git-config?
(or public-inbox-config)  IOW, it's not possible for a
partially-written config file to be read because git-config
writes atomically via rename(2).

Fwiw, the buggy code would be in addr2urlmap called by
_msg_page_prepare in PublicInbox::View.
addr2urlmap() will escape any regexp metacharacters present in
addresses via quotemeta, so there's no chance of regexp
injection from a config.

(hopefully coherent, running on fumes due to real life things)