durusmail: quixote-users: Re: async HTTP server included?
async HTTP server included?
2004-01-06
2004-01-06
Re: async HTTP server included?
2004-01-06
2004-01-06
async HTTP server included?
2004-01-06
Re: async HTTP server included?
2004-01-06
async HTTP server included?
2004-01-07
Re: async HTTP server included?
2004-01-07
2004-01-07
2004-01-07
2004-01-07
Re: Licensing
2004-01-07
2004-01-07
2004-01-07
Pipelining the async HTTP server
2004-01-07
Re: Pipelining the async HTTP server
2004-01-07
2004-01-07
2004-01-08
Re: Pipelining the async HTTP server
2004-01-08
2004-01-08
2004-01-08
2004-01-08
quixote.server.medusa (Re: Pipelining the async HTTP server)
2004-01-08
quixote.server.medusa
2004-01-08
2004-01-12
Re: quixote.server.medusa (Re: Pipelining the async HTTP server)
2004-01-13
Problem with using quixote.server.medusa vs. standalone medusa
2004-01-14
Re: Problem with using quixote.server.medusa vs. standalone medusa
2004-01-14
Resolved! Was Re: [Quixote-users] Re: Problem with using quixote.server.medusa vs. standalone medusa
2004-01-14
Re: Resolved! Was Re: Re: Problem with using quixote.server.medusa vs. standalone medusa
2004-01-14
Pipelining the async HTTP server
2004-01-08
2004-01-08
Re: Pipelining the async HTTP server
2004-01-08
2004-01-08
2004-01-06
Re: async HTTP server included?
2004-01-06
Re: async HTTP server included?
Graham Fawcett
2004-01-07
Jim Dukarm wrote:
> -------------- Quoth Graham Fawcett: -------------
>
> With a very little hacking and sawing, I managed to get my app running
> with the qserver substituted for the Quixote medusa server.

Excellent!

> Right under the part where you create the environ dictionary, I
> inserted this, which I had put into my QuixoteHandler to support basic
> HTTP authentication:
>
>         auth = msg.get('Authorization')
>         if auth:
>             environ['AUTHORIZATION'] = auth


Just FYI, this header item is already available as
environ['HTTP_AUTHORIZATION']. I'm not sure that holds for all Quixote
handlers, but I know it's true for medusa_http, twisted_http, and qserver.
That's the benefit of the "Propagate HTTP headers" section in those handlers.

There was a discussion on the list back in the summer about this; the CGI spec
recommends that all atypical HTTP headers be pushed into the environment with
an HTTP_ prefix. Of course, the benefit to the maintainers of handler code is
that, rather than adding support for obscure header X when user Y needs it, the
HTTP_* model acts as a catchall. (Not suggesting that AUTHORIZATION is an
obscure header field, of course).


> Running everything on localhost:80 (in Windows XP with Opera), I was
> able to bring up my app's dynamically-generated home page and also
> display Help pages, which are gotten to via StaticDirectory. The style
> sheet and app icon, which are StaticFile objects, also were found and
> employed as expected.


That's great news. I need to recheck the CGI variables; I mapped Medusa
attributes onto Pierre's code there, and I may have made a few mistakes. Also,
I'd like to investigate how best to pass the response output to the async
library; I have a feeling that part isn't as efficient as it ought to be.
Lastly, if I read Pierre's code correctly, HTTP connections are being closed at
the end of some responses, at least for responses to POST requests; that seems
quite inefficient. And I'm sure there's more.


> My test was not very extensive, because the thing that I was
> _supposed_ to be working on today has a bug in it that prevents me
> from logging in and displaying other pages.  I suppose I had better
> get back to my official work!


 I've got a motley host of students anxiously awaiting some
resources I was supposed to get online this afternoon; but somehow qserver
became my priority! May their sacrifice not be in vain....

>
> It might be good to move the "from quixote import publish" statement
> down into the test routine, since publish is only referenced down
> there.

Good point; I'll double-check the other imports as well.


> Since the basic page-publishing machinery seems to work, I will leave
> the qserver and its supporting baling wire in place and exercise it
> some more when I get the broken part of my app welded back together.
>
> Thanks, Graham!


Thanks for testing, Jim, and may your welds hold fast!

-- Graham




reply