Hi Ross:

Looks like this bounced and I missed it on Saturday morning.
Posting in the web interface instead. Also you should see the
issue in open status.

I just finished a 16 hour shift, so I am only answering the easy
questions in this email.

On Fri, May 22, 2026 at 10:44 PM Ross Boylan <issues@roundup-tracker.org> wrote:
> Ross Boylan added the comment:
>
> 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.

demo.py (or roundup-demo when Roundup is installed) are meant for
quick demo/testing and trying out
tracker templates.. They are not meant for use if you want to save the
data. So nuke must be specified to
prevent the user from accidentally destroying a demo tracker they
wanted to keep. demo.py IIRC hard codes
the tracker directory name (./demo). roundup-demo accepts/prompts for
a tracker directory so
you can have multiple trackers available.

> Also, are these issues unique to demo.py, or do they apply to the real server?

They are unique to demo.py and roundup-demo. For a real tracker you
would serve the
tracker home directory using roundup-server, wsgi, cgi or some other
method. To change backends
on a real production tracker you would use roundup-admin to migrate
(via import/export) the tracker
to a new backend. This preserves all the data.
See: https://www.roundup-tracker.org/docs/admin_guide.html#migrating-backends.

> > 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.

You should have a checkbox in devtools to disable the cache. If you
enable that you should see a
request for favicon.

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

It won't be on the web page it will be at the left hand side of the
browser tab for 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.

It was my impression that the favicon request was failing but I am not
100% sure why at the moment.
By the time the rest interface call happens you should have already
received the new page. The rest
call is done by a javascript tool in thebackground and if it fails
(with any 4xx code), no harm is done.

> > 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.

It may be since you said Konqueror 20.12.0 worked. It's possible some
check it is doing is looking
at the returned data and sees a sequence of bytes that make it close
the connection abnormally.
It looks like your HTTP/1.0 server change makes it work correctly. So
I am bit stumped here.

Can you set up a new clean profile with firefox just for testing with
Roundup using HTTP/1.1 and see
if you have any issues. I use firefox as my daily driver and can say
that roundup works with it.

> > 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,

You that's fine.

> 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.

The port number is part of the config.ini file under the web property.
If you change web = abd change 8917 to 8918
it would have worked.

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

You are seeing the client requests which advertize that it can handle
HTTP/1.1. If you looked in devtools,
the response headers should have shown HTTP/1.0 advertised IIRC.

> 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 -

That looks like a perfectly fine initial request. No problem there. Is
it throwing a BrokenPipe error?
It doesn't look like it. I do see the differing timezones you
mentioned elsewhere. I'll have to look at that.

> 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 -

This looks like a normal reload using cached copies of all the @@files
and favicon. The /demo/rest
request is an attempt by the class helper to initalize. Since you
aren't logged it it fails
to access the rest endpoint. This is fine and expected.

> 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 -

Again this is fine. Redirect from / to /demo/index using cached files
and the rest check again.

> continued to show HTTP/1.1.

Because the browser is advertising it's HTTP/1.1 capable.

> > 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,

This points to a Firefox config issue or a really weird bug in that
version of Firefox. That's not to say
there isn;t a bug in Roundup that FF is triggering but....

> even though my efforts to use HTTP/1.0 on the server appear to have failed.

Your 1.0 efforts I think worked fine. You just weren't looking in the
proper place (response headers shown
in devtools) for proof.

Since this works I am going to put some blame on the firefox config.
If firefox works with a new empty profile,
it's something in the profile and not the version of firefox that is
causing the issue.

-- rouilj