After hg cloning the source and starting the demo, I pointed my Firefox 140.19.2esr browser at the localhost port the demo said to use. I logged in with demo/demo and got no response.  On the terminal from which the demo launched:

127.0.0.1 - - [18/May/2026 06:15:21] "GET /demo/ HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 06:15:21] "GET /demo/@@file/style.css HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 06:15:21] "GET /demo/@@file/classhelper.js HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 06:15:21] "GET /demo/@@file/datecopy.min.js HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 06:15:22] "GET /demo/rest HTTP/1.1" 403 -
127.0.0.1 - - [18/May/2026 06:15:22] "GET /favicon.ico HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 06:15:49] "POST /demo/ HTTP/1.1" 302 -
127.0.0.1 - - [18/May/2026 06:15:49] "GET /demo/?%40ok_message=Welcome+demo%21 HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 06:15:49] "GET /demo/rest HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 06:15:49] "GET /favicon.ico HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 06:15:49] "GET /favicon.ico HTTP/1.1" 400 -
EXCEPTION AT Mon May 18 06:15:49 2026
Traceback (most recent call last):
  File "/usr/local/src/roundup/roundup/scripts/roundup_server.py", line 275, in run_cgi
    self.inner_run_cgi()
  File "/usr/local/src/roundup/roundup/scripts/roundup_server.py", line 418, in inner_run_cgi
    self.wfile.write(data)
  File "/usr/lib/python3.9/socketserver.py", line 799, in write
    self._sock.sendall(b)
BrokenPipeError: [Errno 32] Broken pipe

There were 2 more broken pipe errors as the attempt to handle the initial exception led to more exceptions (with the same broken pipe error).

Since the server has not returned to the command prompt I guess it's still running and this is not technically a crash.  But it doesn't work.  Not a good look for a first encounter with the system.

Environment
===========

Python 3.9
Debian GNU/Linux 11
I do have a firewall running, but I don't think it covers the loopback interface.  There are various other security systems active, including AppArmor and some process isolation, I think.  Running under SystemD.
Linux barley 5.10.0-42-amd64 #1 SMP Debian 5.10.251-4 (2026-05-08) x86_64 GNU/Linux

I was running as myself, not root.

Hi Ross:

I'm sorry you are running into issues with Roundup.

I tried to duplicate your steps but I am using linux mint 22.3, python 3.12, and firefox 
146.0.1.

Note that 3.9 Python support maybe dropped in Roundup 2.6 due for release in July.
You are running 2.6 by using the repository version rather than a released pip
installed version of Roundup. However, what you are seeing is not expected.

> 127.0.0.1 - - [18/May/2026 06:15:49] "POST /demo/ HTTP/1.1" 302 -
> 127.0.0.1 - - [18/May/2026 06:15:49] "GET /demo/?%40ok_message=Welcome+demo%21 HTTP/1.1" 
200 -
> 127.0.0.1 - - [18/May/2026 06:15:49] "GET /demo/rest HTTP/1.1" 200 -
> 127.0.0.1 - - [18/May/2026 06:15:49] "GET /favicon.ico HTTP/1.1" 200 -
> 127.0.0.1 - - [18/May/2026 06:15:49] "GET /favicon.ico HTTP/1.1" 400 -
> EXCEPTION AT Mon May 18 06:15:49 2026

This is odd, you shouldn't have two favicon requests. Also they shouldn't have
two different statuses: 200 and 400.

When I duplicated your steps, the logging looked the same up to the GET /demo/rest.

After that I do not have the favicon.ico requests. (favicon.ico should have been cached
when the browser loaded the login screen.)

I have a GET for "/demo/?%40template=translation&properties ....." which is the 
classhelper.js module getting translated strings for its interface. Do you have
javascript enabled on your browser?

While I do not get an exception, I get three timeouts after a minute which is expected.

My claim is something is closing the browser/roundup connection.
I am not sure what. Are you experienced in using the firefox devtools, maybe
something on the network tab may shed some light on this.

On the bright side, I think you may have given me a solution to another issue.
It looks like the BrokenPipeError should be trapped and discarded like a 
ConnectionAbortedError.

Roundup runs in many different environments:

   stand alone server (which is used by demo.py)
   behind a proxy (e.g. pound, apache, nginx ... in reverse proxy mode)
   as a wsgi process using a wsgi server (gunicorn, Waitress)
   as a Zope framework module

and all of these handle and expose network and other errors a little differently.

Even though Roundup should not be seeing a BrokenPipeError, it should be handled better.
I'll see if I can make some changes to handle it better.

-- rouilj

Hi Ross:

I'm unable to generate a BrokenPipeError using the tools I have.

However, I do now understand the reason a BrokenPipeError generated
two more exceptions. The last resort Exception handler tries to report
the problem to the client. When the client is gone, it produces more
exceptions when writing to the closed socket.

I added the following near line 284 in roundup/scripts/roundup_server.py:

     except (BrokenPipeError, ConnectionAbortedError, ConnectionResetError) as e:
         self.log_info("Client has gone: %s", e)

right before:

    except Exception:

whose block includes the words "EXCEPTION AT".

Can you patch the code and verify that you do not get a traceback on a BrokenPipeError
and instead get a log message.

Thanks.

-- rouilj

There's an error in the new code: self has no log_info attribute.
Also, I had to add a ) at the end of demo.py before it would run.

As detailed in my comments below, I found some of the messages
from the demo (perhaps actually from the server?) confusing.

Steps
=====

Updated to the latest, 8649 : cafa177776bb.
By the way I looked for the new documentation when your reported it changed for my
other bug, but didn't see it.  It (r8648) did show up a couple of hours later.

Then I applied the change you suggested before line 284 in roundup/scripts/roundup_server.py.  Here's the transcript, with added # commentary.

# On the terminal where I launched the demo yesterday
# Still hadn't returned to prompt, and so probably running.
^CKeyboard Interrupt: exiting
ross@barley:/usr/local/src/roundup$ date; python3 ./demo.py -b sqlite
Mon 18 May 2026 03:25:25 PM PDT
Traceback (most recent call last):
  File "/usr/local/src/roundup/./demo.py", line 5, in <module>
    from roundup.demo import main
  File "/usr/local/src/roundup/roundup/demo.py", line 137
    sys.exit(2)
    ^
SyntaxError: invalid syntax
# Edited demo.py to fix the apparent missing ) at the end of the previous line
ross@barley:/usr/local/src/roundup$ date; python3 ./demo.py -b sqlite
Mon 18 May 2026 03:28:30 PM PDT
Error: Arguments are not allowed when running an existing demo.
       Use the 'nuke' command to start over.
# Since I don't think I am running the demo, since I ^C'd it,
# this error surprised me.  It also made me wonder if it was still
# running, in which case it would have loaded the code before
# the recent edits.  Or it could just mean some lock or configuration
# files were still around.
ross@barley:/usr/local/src/roundup$ date; python3 ./demo.py nuke
Mon 18 May 2026 03:28:53 PM PDT
Initializing demo instance in:
    /usr/local/src/roundup/demo
Nuking directory left from the previous demo instance.
Trying to set up web server on port 8917 ...
# same port, which argues against the previous instance being active
should be ok.

# ... [boilerplate deleted]
# but it says to change backend types I must use nuke.
# but I just used nuke...

^CKeyboard Interrupt: exiting
ross@barley:/usr/local/src/roundup$ date; python3 ./demo.py nuke
Mon 18 May 2026 03:29:34 PM PDT
Initializing demo instance in:
    /usr/local/src/roundup/demo
Nuking directory left from the previous demo instance.
Trying to set up web server on port 8917 ...
should be ok.

Demo Tracker Home: /usr/local/src/roundup/demo
Server running - connect to:

    http://localhost:8917/demo/

# ... deletions
# At this point I pointed Firefox at the port

127.0.0.1 - - [18/May/2026 15:31:10] "GET / HTTP/1.1" 302 -
127.0.0.1 - - [18/May/2026 22:31:11] "GET /demo/index HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 22:31:11] "GET /demo/@@file/style.css HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 22:31:11] "GET /demo/@@file/classhelper.js HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 22:31:11] "GET /demo/@@file/datecopy.min.js HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 22:31:11] "GET /demo/rest HTTP/1.1" 403 -
127.0.0.1 - - [18/May/2026 22:31:12] "GET /favicon.ico HTTP/1.1" 200 -
# and here it stopped for awhile
# I don't think I touched any of the controls on the window, and certainly
# did not try to login
127.0.0.1 - - [18/May/2026 22:32:12] Request timed out: timeout('timed out')
# after seeing the previous message, I did try to login as demo
127.0.0.1 - - [18/May/2026 22:32:23] "POST /demo/ HTTP/1.1" 302 -
127.0.0.1 - - [18/May/2026 22:32:23] "GET /demo/index?%40ok_message=Welcome+demo%21 HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 22:32:23] "GET /demo/rest HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 22:32:23] "GET /favicon.ico HTTP/1.1" 200 -
----------------------------------------
Exception occurred during processing of request from ('127.0.0.1', 43348)
Traceback (most recent call last):
  File "/usr/local/src/roundup/roundup/scripts/roundup_server.py", line 275, in run_cgi
    self.inner_run_cgi()
  File "/usr/local/src/roundup/roundup/scripts/roundup_server.py", line 420, in inner_run_cgi
    self.wfile.write(data)
  File "/usr/lib/python3.9/socketserver.py", line 799, in write
    self._sock.sendall(b)
BrokenPipeError: [Errno 32] Broken pipe

# Since there is no "Client has gone" message, it seems the new
# except clause didn't activate. However it's the next reported 
# error, and so this may just reflect the order in which nested errors
# are reported.
# Line 275 is reported as the most 
# recent call, and it certainly looks as if it's covered by the new except

# The next failure definitely reflects the new code.
# Unfortunately, the new code has an error.


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/socketserver.py", line 616, in process_request
    self.finish_request(request, client_address)
  File "/usr/lib/python3.9/socketserver.py", line 360, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib/python3.9/socketserver.py", line 720, in __init__
    self.handle()
  File "/usr/local/src/roundup/roundup/scripts/roundup_server.py", line 333, in handle_method_wrapper
    http_.server.BaseHTTPRequestHandler.handle(self)
  File "/usr/lib/python3.9/http/server.py", line 436, in handle
    self.handle_one_request()
  File "/usr/lib/python3.9/http/server.py", line 422, in handle_one_request
    method()
  File "/usr/local/src/roundup/roundup/scripts/roundup_server.py", line 285, in run_cgi
    self.log_info("Client has gone: %s", e)
AttributeError: 'RequestHandler' object has no attribute 'log_info'
----------------------------------------
127.0.0.1 - - [18/May/2026 22:32:23] "GET /demo/?%40template=translation&properties=apply%2Ccancel%2Cnext%2Cprev%2Csearch%2Creset%2CInfo+on+%7BclassName%7D+-+%7BitemDesignator%7D+-+Classhelper HTTP/1.1" 200 -
127.0.0.1 - - [18/May/2026 22:33:23] Request timed out: timeout('timed out')
# timeouts seem to be after 60s

javascript is enabled in my browser.

After my seemingly abortive login I activate devtools in FF and hit the logout button on the demo screen.

The devtools log under network shows a series of successful GET and then one with Status 403 (denied).  The file column says "rest" and the initiator is classhelper.js:1371.  There is one successful GET after for favicon.ico, which is reported as cached.

Hi Ross:

I'm including another dev on this. I am rapidly running out of ideas as to the cause 
here. Ralf, if you have a chance can you look at this issue and see if you have any 
ideas?

Covering a couple of replies here:

> Also, I had to add a ) at the end of demo.py before it would run.

You are correct I was missing a close ) on the prior line. That is fixed.
I incorrectly transcribed the line from the live CD devel system to the
system I use for checkin. I am using a live CD booted system so I can be
sure I am running in a clean system.

> There's an error in the new code: self has no log_info attribute.

self.log_info() should be self.log_message()

Regarding:

> Error: Arguments are not allowed when running an existing demo.
>       Use the 'nuke' command to start over.

just run 'python ./demo.py' with no arguments. It will discover the existing
demo tracker and serve it. The directions from the script say:

  1. Log in as "demo"/"demo" or "admin"/"admin".
  2. Hit Control-C to stop the server.
  3. Re-start the server by running "./demo.py" again.
  4. Reset the tracker by running "./demo.py nuke".

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

demo.py always uses ./demo as the tracker home directory. If run 
without arguments it prompts you for database etc. interactively.
All the arguments are for use when recreating a tracker.

It looks like the traceback in msg8441 has the sequence I expect.

> 127.0.0.1 - - [18/May/2026 15:31:10] "GET / HTTP/1.1" 302 -
> 127.0.0.1 - - [18/May/2026 22:31:11] "GET /demo/index HTTP/1.1" 200 -
> 127.0.0.1 - - [18/May/2026 22:31:11] "GET /demo/@@file/style.css HTTP/1.1" 200 -
> [... 2 lines]
> 127.0.0.1 - - [18/May/2026 22:31:11] "GET /demo/rest HTTP/1.1" 403 -

The 403 is expected as you have not logged in yet. So you are the anonymous
user. The anonymous user doesn't have permissions to use the rest interface
and gets a 403.

> 127.0.0.1 - - [18/May/2026 22:31:12] "GET /favicon.ico HTTP/1.1" 200 -
> # and here it stopped for awhile

Yup the request is done. Nothing more to do until you touch the browser.

> # I don't think I touched any of the controls on the window, and certainly
> # did not try to login
> 127.0.0.1 - - [18/May/2026 22:32:12] Request timed out: timeout('timed out')

Timeout about 1 minute after the last message as expected.

> # after seeing the previous message, I did try to login as demo
> 127.0.0.1 - - [18/May/2026 22:32:23] "POST /demo/ HTTP/1.1" 302 -
> 127.0.0.1 - - [18/May/2026 22:32:23] "GET /demo/index?%40ok_message=Welcome [...] 
> 127.0.0.1 - - [18/May/2026 22:32:23] "GET /demo/rest HTTP/1.1" 200 -

This GET succeeds since you have logged in as demo. The demo user has the
role 'user' which does have permission to access the rest interface.

> 127.0.0.1 - - [18/May/2026 22:32:23] "GET /favicon.ico HTTP/1.1" 200 -
----------------------------------------
Exception occurred during processing of request from ('127.0.0.1', 43348)
Traceback (most recent call last):
  File "/usr/local/src/roundup/roundup/scripts/roundup_server.py", line 275, in 
run_cgi
    self.inner_run_cgi()
  File "/usr/local/src/roundup/roundup/scripts/roundup_server.py", line 420, in 
inner_run_cgi
    self.wfile.write(data)
  File "/usr/lib/python3.9/socketserver.py", line 799, in write
    self._sock.sendall(b)
BrokenPipeError: [Errno 32] Broken pipe
# Since there is no "Client has gone" message, it seems the new
# except clause didn't activate. However it's the next reported 
# error, and so this may just reflect the order in which nested errors
# are reported.

I think you are right. Since the exception code threw an exception 8-/, it just 
dumped the exceptions in creation order.

# Line 275 is reported as the most 
# recent call, and it certainly looks as if it's covered by the new except
# The next failure definitely reflects the new code.
# Unfortunately, the new code has an error.

Replace log_info with log_message() as above and see if that generates the
Client has gone message.

As to why you are getting the BrokenPipeError, I still have no idea. That
code is doing the following:

    buffer the status response,
    buffer some headers,
    end headers which writes the buffered headers and IIRC a blank line using
         self.wfile.write. So at this point the client connection is open.

then we try to write the data and get the BrokenPipeError indicating the
client connection is closed. My WAG is that something in the headers is
causing the issue. My WAG was that this call:

            self.send_header('Content-Length', len(favico))

is sending 0 as the len of favico. That could cause the browser to close the
connection since there is nothing to read. However we already got the favico
in the original get and it should be cached. I also just tried replacing
len(favico) with 0 (and 20) and I don't get a BrokenPipeError in my environment.
This is with Roundup running in HTTP/1.1 or HTTP/1.0 modes.

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.

You orginally reported:

> I logged in with demo/demo and got no response.

This is really weird as you indicated that you are actually logged in.
The favicon failing shouldn't change anything as it is a totally separate
request. You got the login page back according to the logs. Do you have any
Firefox plugins that act as sanitizers or block bad pages?

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

roundup_server is what demo.py is running under the hood.
This should cause roundup_server to use HTTP version 1.0 rather than the
default of version 1.1. So every connection is closed after the response.
This should eliminate the timeout log as well.

Do you have another graphical browser available? You can use a text mode browser
like w3m or lynx, but they won't get the favicon which is where things fail.
I doubt curl for favico would trigger the issue. Trying a different version of
firefox or chrome might be helpful. You can change demo/config.ini's 'web' stting
from localhost:8917 to hostname:8917 and try connecting from another computer if
you have one.

Thanks for bringing me an interesting problem.

-- rouilj

With change from log_info to log_message I'm still getting a broken pipe error, but it no longer seems to block me from logging in.

# pointed browser at the port
127.0.0.1 - - [22/May/2026 11:46:30] "GET / HTTP/1.1" 302 -
127.0.0.1 - - [22/May/2026 18:46:30] "GET /demo/index HTTP/1.1" 200 -
127.0.0.1 - - [22/May/2026 18:46:32] "GET /demo/@@file/style.css HTTP/1.1" 200 -
127.0.0.1 - - [22/May/2026 18:46:32] "GET /demo/@@file/datecopy.min.js HTTP/1.1" 200 -
127.0.0.1 - - [22/May/2026 18:46:32] "GET /demo/rest HTTP/1.1" 403 -
127.0.0.1 - - [22/May/2026 18:46:32] "GET /favicon.ico HTTP/1.1" 200 -
# and here's the Broken pipe, as reported by the new error handler
127.0.0.1 - - [22/May/2026 18:46:32] Client has gone: [Errno 32] Broken pipe

# wait and do nothing, then login to demo in the browser
127.0.0.1 - - [22/May/2026 18:47:11] "POST /demo/ HTTP/1.1" 302 -
127.0.0.1 - - [22/May/2026 18:47:11] "GET /demo/index?%40ok_message=Welcome+demo%21 HTTP/1.1" 200 -
127.0.0.1 - - [22/May/2026 18:47:12] "GET /demo/rest HTTP/1.1" 200 -
127.0.0.1 - - [22/May/2026 18:47:12] "GET /demo/?%40template=translation&properties=apply%2Ccancel%2Cnext%2Cprev%2Csearch%2Creset%2CInfo+on+%7BclassName%7D+-+%7BitemDesignator%7D+-+Classhelper HTTP/1.1" 200 -

127.0.0.1 - - [22/May/2026 18:47:40] "GET /demo/issue?@template=item HTTP/1.1" 200 -
127.0.0.1 - - [22/May/2026 18:47:40] "GET /demo/rest HTTP/1.1" 200 -
127.0.0.1 - - [22/May/2026 18:47:40] "GET /demo/rest/data/status?@verbose=2 HTTP/1.1" 200 -
127.0.0.1 - - [22/May/2026 18:47:40] "GET /demo/?%40template=translation&properties=title%2Cstatus%2Ckeyword%2Cid%2Cusername%2Crealname%2Cphone%2Caddress%2Cname%2Capply%2Ccancel%2Cnext%2Cprev%2Csearch%2Creset%2CInfo+on+%7BclassName%7D+-+%7BitemDesignator%7D+-+Classhelper HTTP/1.1" 200 -
127.0.0.1 - - [22/May/2026 18:47:40] "GET /demo/rest/data/keyword?@verbose=2 HTTP/1.1" 200 -
# during this time I fiddled with the FF web tools, but did not interact with the page
127.0.0.1 - - [22/May/2026 18:48:40] Request timed out: timeout('timed out')
127.0.0.1 - - [22/May/2026 18:48:40] Request timed out: timeout('timed out')

More later.

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?

One other oddity about the logs: most of the GET times seem to be UTC, but some of them are local time (US/Pacific, currently -0700).

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

Also Ross if you get another codec error, check to see if you have smart quotes and not ascii 
double quotes in your text.

Hi Ross:

> One other oddity about the logs: most of the GET times seem to be UTC,
> but some of them are local time (US/Pacific, currently -0700).

Yup I realized there's a pattern there. If the URL is inside the tracker, the UTC timezone
is printed. If the URL is outside the tracker you get the system timezone: US/Pacific.

This is inside tracker '/demo/' and timezone is set in config.ini
with the [main] timezone setting to UTC or 0:
> 127.0.0.1 - - [23/May/2026 02:07:10] "GET /demo/rest HTTP/1.1" 403 -

This is outside the tracker, so using system timezone.
> 127.0.0.1 - - [22/May/2026 19:07:10] "GET /favicon.ico HTTP/1.1" 200 -

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

Outside:
> 127.0.0.1 - - [22/May/2026 19:08:57] "GET / HTTP/1.1" 302 -

Inside:
> 127.0.0.1 - - [23/May/2026 02:08:57] "GET /demo/index HTTP/1.1" 200 -

Roundup server can serve multiple trackers with only one server. So you could
have one tracker for the German office in the Europe/Berlin timezone by default
and one for the New York office in America/Eastern. Both can be served by
the same roundup-server. Each user of the tracker can also set their own timezone
offset. So a user in California can see times in the German tracker in their local
US/Pacific time.

So what you observed makes perfect sense. What to do about it, if anything,
is less obvious. There are a number of ways to server roundup some of which
generate their own logs that are independent of Python logging.
I opened issue 2551418 to track/discuss.

Concerning the different timezones in the logs: We may want to add a logging-timezone setting: If we're running several trackers with different timezones in a single server we may want the logging to be in a consistent timezone.

Not very urgent, though, because I think anyone hosting multiple sites will do so in a (u)wsgi server behind a webserver, so logging there is using other facilities that already generate consistent timestamps for log entries.