Here are the mostly unsatisfying response to your other questions.

> Would it be better if 3 reads:
>  
>  3. Re-start the server by running "./demo.py" without any arguments.

That is more explicit, but I got that already.  What I don't get is what one should do if one wants to switch database backends, i.e., use the -b argument.  Also, are these issues unique to demo.py, or do they apply to the real server?

> Can you use the devtools to look at the login sequence and see what the favicon
> request looks like. The headers tab for the favico request should show a
> Content-Length of 1406 and the response tab should show the cowboy on a 
> horse.

I am no longer seeing the favicon requests in the network tab of the  FF web tools.  I'm guessing there has been sufficient caching to avoid it (well, that logic doesn't quite work: previously I saw the requests and it showed "cached".  So why stop now?). I tried clearing cookies and associated storage, but it didn't help.

I do not see a cowboy icon on the web page.

I guessed the problem was not with favicon but the request after, which uses the rest interface.  But I also don't see that in the recent network traces.

> Do you have any Firefox plugins that act as sanitizers or block bad pages?

First, my recollection of the history of the demo login may have been faulty.

Second, I have an adblocker active, and have custom security settings in FF.  In FF | Settings | Privacy & Security | Browser Privacy | Enhanced Tracking Protection the setting is custom.  Everything except Cookies is blocked.  This warning appears:

This setting may cause some websites to not display content or work correctly. If a site seems broken, you may want to turn off tracking protection for that site to load all content. Learn how

I don't know if any of that is relevant.

> One other thing to try is to rather than running demo.py run:

>   python roundup/scripts/roundup_server -p 8917 -V HTTP/1.0 demo=demo

I used python3 instead of python, and initially used port 8918 in hopes of avoiding cached data.  It never really worked, and kept ending up back at port 8917.  I presume the saved setup was taking over.  So I reran with -p 8917.

With 8918 I did get a reference to favicon, but not, apparently, the use of HTTP 1.0:

ross@barley:/usr/local/src/roundup$ date; python3 roundup/scripts/roundup_server.py -p 8918 -V HTTP/1.0 demo=demo
Fri 22 May 2026 07:06:36 PM PDT
Roundup server started on localhost:8918
127.0.0.1 - - [22/May/2026 19:07:09] "GET / HTTP/1.1" 302 -
127.0.0.1 - - [23/May/2026 02:07:09] "GET /demo/index HTTP/1.1" 200 -
127.0.0.1 - - [23/May/2026 02:07:10] "GET /demo/@@file/classhelper.js HTTP/1.1" 200 -
127.0.0.1 - - [23/May/2026 02:07:10] "GET /demo/@@file/datecopy.min.js HTTP/1.1" 200 -
127.0.0.1 - - [23/May/2026 02:07:10] "GET /demo/@@file/style.css HTTP/1.1" 200 -
127.0.0.1 - - [23/May/2026 02:07:10] "GET /demo/rest HTTP/1.1" 403 -
127.0.0.1 - - [22/May/2026 19:07:10] "GET /favicon.ico HTTP/1.1" 200 -
127.0.0.1 - - [23/May/2026 02:07:42] "GET /demo/index HTTP/1.1" 200 -
127.0.0.1 - - [23/May/2026 02:07:42] "GET /demo/rest HTTP/1.1" 403 -
127.0.0.1 - - [22/May/2026 19:08:57] "GET / HTTP/1.1" 302 -
127.0.0.1 - - [23/May/2026 02:08:57] "GET /demo/index HTTP/1.1" 200 -
127.0.0.1 - - [23/May/2026 02:08:58] "GET /demo/rest HTTP/1.1" 403 -
^CKeyboard Interrupt: exiting

Using port 8917 did allow me to login; the log showed no references to favicon, but it did show a reference to rest.  And it continued to show HTTP/1.1.

> Do you have another graphical browser available?

Yes. Konqueror 20.12.0.  I do not see an analog to FF's web tools for it (though they must exist).
Using it, everything seemed to work OK, even though my efforts to use HTTP/1.0 on the server appear to have failed.

Ross

P.S. Should I be setting the status to open on these followup posts?