At 08:46 AM 6/2/00 -0400, Dave Wallace wrote:
>Chuck Esterbrook wrote:
>
> >
> > >Even more interesting would be a mod_python adapter. Unfortunately, I
> am some
> > >distance from understanding either mod_python or WebKit well enough to do
> > >this. I did
> > >some experimentation, but I could only get the mod_python's CGI emulator
> > >to work
> > >sporatically with WebKit.cgi
> > >
> > >Dave.
> >
> > Agreed. I don't know much about mod_python, but I can certainly try to
> > answer any questions you have about WebKit.cgi/CGIAdaptor.py.
>
>I played around with mod_python a little more last night, but it seems
>that the
>content-type is getting occasionally scrambled (i.e. replaced with a
>random(!?)
>python object instead of the string I put there) no matter if I use
>mod_python's
>cgihandler or write my own handler. It looks like a problem with mod_python
>itself, so hopefully I can come up with a minimal test case to verify that
>over
>the weekend.
Sounds like a good plan.
>One interesting thing that I have come across is that apparently Apache and
>therefore mod_python require headers to be sent separately from the subsequent
>output stream. That is they must be set individually within an Apache table
>object. Unfortunately, HTTPResponse combines them into a single string to
>be sent
>all at once, the upshot being that my mod_python handler must parse the
>headers
>out again. Perhaps this behavior could be based upon the value of the 'format'
>key in the dictionary that is passed from the handler and the decision to
>combine
>the headers moved into the Application or maybe a related object that can
>encapsulate code for different handlers?
Ah, juicy. Well the essence of an HTTPResponse is to have headers and a
content, but the delivery needs to be the responsibility of the adaptor
which should receive back a dictionary with headers, cookies & contents and
then "do the right thing".
This was a design/implementation flaw on my part.
I can restructure this right after the 0.3 release on Monday. I don't want
to muck with it before the release.
There is another flaw in WebKit's HTTPRequest where it assumes it has a
CGI-like environment to pull info from. That will also get flushed out as
we integrate WebKit in other ways.
>Also, just on the off-chance that this is helpful: in the mod_python
>cgiadapter
>the os.environ is reset to a plain dictionary with a note claiming tha the
>enviorn object leaks memory if it is manipulated too often (as in the case of
>multiple cgi transactions). I haven't kept up with you leak tracking but maybe
>this is a clue?
I don't think we set the environment, I think we just read it. But that's
interesting to keep in mind.
-Chuck
|