Here are the gory details of my re-run today of the Quixote-Medusa
server test. I am running in Windows XP with a stock installation of
Python Labs Python 2.2.2. Medusa was downloaded and installed at the
same time as Quixote.

1) Create modified version of medusa_http.main() to specify IP
127.0.0.1 and port 80, and also to enable logs. Also invoke the
modified method in the 'if __name__ ==...' section at the bottom of
the module.

def main2 ():
    from quixote import enable_ptl
    enable_ptl()
    print 'Now serving the Quixote demo on port 80'
    server = http_server.http_server('127.0.0.1', 80)  # ORIG IP WAS ''
    publisher = Publisher('quixote.demo')
    publisher.setup_logs()  ### JJD ADDITION
    dh = QuixoteHandler(publisher, 'Quixote/demo', server)
    server.install_handler(dh)
    asyncore.loop()

2) Start the Quixote-Medusa server by double-clicking medusa_http.py.
This feeds the module to my default python.exe in C:\Python22.  The
console window shows that Medusa is using Hostname: localhost and
Port: 80. (I stopped Xitami before doing this experiment, to avoid
conflicts).

3) Point the browser (MSIE 6.0) to http://localhost/ , then
http://localhost/simple , http://localhost/3
Each time, the browser displays a "This page cannot be displayed"
message and reports HTTP 500 - Internal server error.  The Medusa
console window displays a row of information for each of the
requests.

At this point, the access and errors logs are empty, but the debug log
contains four messages. The fourth message is apparently truncated
because the output buffer was not flushed. (See log contents below).

4) Point the browser to http://localhost/ again, then
http://localhost/5/, http://localhost/widgets,
http://localhost/form_demo, http://localhost/7/factorial, and finally
http://localhost/junk.
Each time, the result is HTTP 500 - Internal server error. The Medusa
window shows 9 sensible-looking requests.

5) Shut the Quixote-Medusa server down by closing its window. The
access and errors logs are still empty, and the debug log contains
eleven messages. Evidently, each of the two attempts to access the
demo root successfully triggered the 'debug message' plus an
additional error entry. The very last entry shows that my invalid URL
referencing 'junk' was (as expected) fed through the integer_ui
module, which recognized it as a non-integer. This is what was
happening with the many invalid URL's I tried previously, when I was
not sure that http://localhost/ was the correct starting point.

-------- debug log contents ------------
debug message from the index page
error: Server Error: exceptions.AttributeError, Publisher instance has no
attribute 'start_time': file: c:\python22\Lib\site-packages\quixote\publish.py
line: 230
error: Server Error: exceptions.AttributeError, Publisher instance has no
attribute 'start_time': file: c:\python22\Lib\site-packages\quixote\publish.py
line: 230
error: Server Error: quixote.errors.TraversalError,
: file:
c:\python22\Lib\site-packages\quixote\publish.py line: 539
debug message from the index page
error: Server Error: exceptions.AttributeError, Publisher instance has no
attribute 'start_time': file: c:\python22\Lib\site-packages\quixote\publish.py
line: 230
error: Server Error: exceptions.AttributeError, Publisher instance has no
attribute 'start_time': file: c:\python22\Lib\site-packages\quixote\publish.py
line: 230
error: Server Error: exceptions.AttributeError, Publisher instance has no
attribute 'start_time': file: c:\python22\Lib\site-packages\quixote\publish.py
line: 230
error: Server Error: exceptions.AttributeError, Publisher instance has no
attribute 'start_time': file: c:\python22\Lib\site-packages\quixote\publish.py
line: 230
error: Server Error: exceptions.AttributeError, Publisher instance has no
attribute 'start_time': file: c:\python22\Lib\site-packages\quixote\publish.py
line: 230
error: Server Error: quixote.errors.TraversalError, invalid literal for int():
junk: file: c:\python22\Lib\site-packages\quixote\demo\integer_ui.py line: 19
----------------------------------------

A cursory examination of publish.py line 230 etc. seems to indicate
start_time should have been set but wasn't, but I am not yet clued
in enough in Quixote internals to follow through and recommend a fix.
This error does not occur when running the demo as a CGI app in
Xitami. In that case (going through an analogous sequence of URLS, all
with base http://127.0.0.1/cgi-bin/qdemo/) the Quixote access log
shows seven entries (one for each of the valid demo URLs used), and
the debug log shows two instances of the 'debug message from the index
page', as expected.

Regarding the trailing-slash-or-not issue that I commented on in
connection with my Xitami+Quixote test, I had thought that all the
redirection was on the server end.  I did read the docs, but evidently
that part of the material did not register the first time I read it.

While grubbing around in quixote.config.py just now, I found the
FIX_TRAILING_SLASH parameter. I will play with that.

By the way, the Quixote 'setup install' omits copying several files,
including several of the demo modules (e.g. all the .cgi files and
demo.conf) as well as the entire doc folder. That's why I wrote my own
cgi driver for the demo -- I didn't notice that it already existed.

Many thanks for the detailed response.

Jim Dukarm
DELTA-X RESEARCH

> On 01 November 2002, Jim Dukarm said:
>> I installed Quixote and a freshly-downloaded copy of Medusa on my
>> Windows XP system (with Python 2.2.2) and, after starting the Quixote
>> Medusa-based server, was unable to guess the correct URI for viewing
>> the demo pages. Log entries indicate that most of the 25 or so URI's
>> that I tried were processed by the Quixote machinery and ended up
>> triggering a TraversalError (invalid literal for int()) on line 19 of
>> integer_ui.py.

> That's weird.  Can you give more detail, ie. which URL resulted in what
> error message being written to which log file?

>> Question: What should the URI be for running the demo with the
>> Medusa server?  (I tried things like "http://cygnus/",
>> "http://cygnus/Quixote/demo", etc., where "cygnus" is the hostname of
>> my PC, and the server is configured to listen on cygnus port 80 and is
>> definitely doing so).

> Define "the server".  If Quixote-via-Medusa is listening to port 80
> itself, then I would expect http://cygnus/ to work.  What does Quixote
> write to its log files when you access that URL?  And which of Quixote's
> three log files are enabled in your setup?

>> After that experiment, I downloaded and installed the Xitami web
>> server (www.xitami.com), cobbled up a CGI driver script 'qdemo' for
>> the Quixote demo, and was immediately successful in running the demo.
>> The driver script is simply a literal copy of the simple one suggested
>> in the demo documentation.
>>
>> When I pointed the browser to "http://cygnus/cgi-bin/qdemo/", the
>> links on the demo home page worked properly.

> Good -- Quixote itself is working fine; there's just something odd with
> using Quixote as its own web server.

>> When I pointed the
>> browser to "http://cygnus/cgi-bin/qdemo" (no trailing slash), the home
>> page links were dead. For example, the 'simple' link evidently tried
>> to activate "http://cygnus/cgi-bin/simple", which of course failed. If
>> I typed in the URI "http://cygnus/cgi-bin/qdemo/simple", I got the
>> "simple" page as expected.

> Right, this stuff is all explained in gory detail in doc/demo.txt and
> doc/web-server.txt (also available on the Quixote web site).  Have you
> read those docs yet?

>> It seems to me that if "_q_index", "simple", "error", "widgets", and
>> "form_demo" are all in the "demo" namespace, which is like having
>> .html files all in the same directory, then relative references such
>> as those in _q_index() should always work, regardless of whether the web
>> server is configured to do "magical" URI renaming (sly dig) to conceal
>> the "cgi-bin/qdemo" reference in the URI's.

> This is not a web server issue -- it's all client-side.  The "magical"
> redirect is absolutely required for the client (browser) to get it
> right.

> Try creating a regular old directory in your URL-space, say "/foo", and
> point your browser at it.  Your web server will almost certainly
> redirect your "/foo" request to "/foo/", because it knows that otherwise
> your browser will get internal redirects wrong.  (More precisely, the
> browser will have a different understanding of "internal" from what you
> had when you constructed that web-space.)  Web servers can do this
> automatically for URL-spaces generated from the filesystem, because it's
> easy to spot directories in that case.  For URL-spaces generated from a
> Python package tree, though, it's not possible -- either you or Quixote
> need to do the redirect.  It's just faster if you do it in the web
> server config.

>         Greg