December 1999 - Zope-Dev

Plain text version of HTTPRequest
by Andrew M. Kuchling 13 Dec '99

13 Dec '99

The __str__() method of HTTPRequest objects produce formatted HTML. For the purposes of e-mailing tracebacks, I'd like a plain ASCII version of the same information. If I added a method (say, .dump()) that generated a plain text version, would it be accepted into the CVS tree? -- A.M. Kuchling http://starship.python.net/crew/amk/ BTW, I learned a lovely new acronym today: "Law Enforcement Agency Key" - LEAK. -- Charles H. Lindsey

1 0

problems with file caching
by Jonothan Farr 13 Dec '99

13 Dec '99

I'm running into a few problems getting file caching to work correctly with the Local File System product. I am using the version 2.1.0 source distribution. The first problem has to do with the index_html() method of the File class in OFS/image.py. Line 188 says: if self._p_mtime > ms: RESPONSE.setStatus(304) return RESPONSE What this seems to say to me is, "If my modification time is later than the modification time of the cached file then send a 304 (Not Modified) response." If I'm not mistaken, this is exactly the opposite of what the HTTP specification says about the If-Modified-Since header. So, line 188 should say: if self._p_mtime <= ms: ... Secondly, once that modification is made I noticed that the DateTime class seems to be making slight rounding errors when parsing the http date string which is also throwing off the caching. To test this, I wrote a very simple http proxy so I can see what's being sent back and forth. I also added some debugging output to the image.py file. ms=DateTime(ms).timeTime() import time print 'ms:', time.ctime(ms), '(%.8f)' % ms print 'mtime:', time.ctime(self._p_mtime), '(%.8f)' % self._p_mtime print 'not modified:', self._p_mtime <= ms if self._p_mtime <= ms: Here's an example transaction that should send a 304 response. send: 'GET /local/gifs/python.gif HTTP/1.0\015\012' send: 'user-agent: Mozilla/4.6 [en] (WinNT; I)\015\012' send: 'accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*\015\012' send: 'authorization: Basic YWRtaW46bGV0bWVpbg==\015\012' send: 'accept-encoding: gzip\015\012' send: 'if-modified-since: Wed, 15 Sep 1999 21:11:30 GMT; length=649\015\012' send: 'cookie: tree-s="eJyLjlZ3hANPW/XYWAAtiQTP"\015\012' send: 'proxy-connection: Keep-Alive\015\012' send: 'referer: http://localhost:8080/local/gifs\015\012' send: 'host: localhost:8080\015\012' send: 'accept-charset: iso-8859-1,*,utf-8\015\012' send: 'accept-language: en\015\012' send: '\015\012' reply: 'HTTP/1.0 200 OK\015\012' reply: server: Zope/Zope 2.0.0b5 (binary release, python 1.5.2, win32-x86) ZServer/1.1b1 reply: content-length: 649 reply: content-type: image/gif reply: connection: close reply: last-modified: Wed, 15 Sep 1999 21:11:30 GMT reply: date: Thu, 09 Dec 1999 22:11:00 GMT Here's the debug output: ms: Wed Sep 15 14:11:29 1999 (937429889.99999952) mtime: Wed Sep 15 14:11:30 1999 (937429890.00000000) not modified: 0 As you can see, the request header says: if-modified-since: Wed, 15 Sep 1999 21:11:30 GMT; length=649 and the response header says: last-modified: Wed, 15 Sep 1999 21:11:30 GMT but the DateTime class converts this time to: Wed Sep 15 14:11:29 1999 which is off by one second, so it thinks that the file has in fact been modified. The workaround I came up with for this is to round off the time value generated by the DateTime class. ms=DateTime(ms).timeTime() ms = round(ms, 1) If I am correct, and this is actually a problem with the DateTime class, I would like to see it fixed, though. I'm not sure whether my third problem is a problem with Zope or my web browser (Netscape 4.6). What happens is that once the browser sends a request with an 'If-Modified-Since' header and the server responds with 200 (OK) instead of 304 (Not Modified), the browser never sends an 'If-Modified-Since' header again unless I restart the browser or clear the cache. In other words, if it tries to use the cached file and finds that it's out of date then it never tries to use the cached file again. I suspect that this is a problem with Netscape, though, and there's nothing I can really do about it. I am interested in any and all feedback regarding these problems. I would like to know if I have found some valid bugs here and should submit them to the collector. Thanks, --jfarr

3 5

RE: [Zope-dev] Object ownership
by Michel Pelletier 13 Dec '99

13 Dec '99

> -----Original Message----- > From: Ross Boylan [mailto:rboylan@mindspring.com] > > > 2) So User objects have an owner of superuser, not themselves. > > > > huh? > My thinking here is that a user doesn't exist until after the > User object > (in acl_users) is created. Ordinarily, one needs to be a > manager to do so. > So the question is, does the manager own the User object, or > does the newly > created user own that object. It is undefined whether or not User objects are owned. Some implimentations may have users with owners, some may not (UserDB is an example where they don't). Basicly, don't depend on User object having owners, consider it undefined and may change without notice. -Michel

2 1

Seeking help on Replication/'Automatic Copying' of a zope server
by Nick Howden 13 Dec '99

13 Dec '99

Hi, Does anyone have any insights into the problem below (note the one way connection) I am currently using Zope on two web servers which run on different networks. I use one as the master/development machine and the second machine contains purely a slave copy of the zope code. At the moment I keep the 2nd machine's zope code upto date with a manual disk copy but this seems a little kludgy. I am constrained by the fact that there is only a one way link from the master to the slave (so I can't get any confirmation of connections, etc) Any ideas on how I can improve my replication process? Thanks in advance for any useful pointers. Nick Howden (N.Howden(a)eris.dera.gov.uk) Senior IT Analyst - Defence Evaluation and Research Agency Tel: +44 (0)1684 895566 Fax: +44 (0)1684 894303 The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the intended recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

1 0

RE: [Zope-dev] Object ownership
by Michel Pelletier 13 Dec '99

13 Dec '99

> -----Original Message----- > From: Ross Boylan [mailto:RossBoylan@stanfordalumni.org] > Sent: Sunday, December 12, 1999 9:22 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] Object ownership > > > I've been making some assumptions about how ownership works, and I'd > appreciate it if anyone could tell me if they are right. > > 1) The owner of an object is the authenticated user when the > script that > creates it runs. Correct. > 2) So User objects have an owner of superuser, not themselves. huh? > 3) I can programmatically create an object graph, and the > ownership of the > parts of the graph will be right. The owner of the parts will be the user that created them. -Michel

2 1

Documentation Solution
by Eron Lloyd 13 Dec '99

13 Dec '99

As a member of the ZDP, as well as several other Documentation Projects, I understand exactly where these complaints are coming from. I'm still in the learning stage of Zope, and I admit, am stumbling over the current *official* documentation; nonetheless, I think I'm gaining a foothold. I'm not going to say what Digital Creations should do about this dilemma, but present several options: 1. Create a good communication with the ZDP. As far as I know, not much if any of the ZDP's effort has made it into official documentation. Let's encourage eachother, not point fingers. Let writers know that they are needed; even better, compile a list of EXACTLY what needs to be written/updated. 2. Have volunteers mine the mail archives and compile notes. There is TONS of excellent questions/answers to real world situations on everything Zope. Let's start going through and indexing them. 3. Put together TUTORIALS. If you know how to do something, document it. I'm sure someone would appreciate it. Contact the ZDP, and we'll put up a good collection. 4. Proofread. Many of the Official Guides have typos and broken code examples. Let Pam know. A simple page# description would help ALOT. 5. NEWBIES: Instead of just requesting help on something, request someone to make a How-to. This is another way we can gather priceless material instead of letting it dissolve into the mail archives. 6. A Hypertext help-system integrated into the Zope installation. 7. What tools? Here are some tools we could decide to use for docs (+/-): - DocBook SGML/XML DTD: Powerful, standardized; yet complex - VERY complex. - StarOffice: good Word Processor, supports multi-user docs (redlining, etc.), free; Big, some say bloated. - Structured Text: native to Zope, easy to write in; not functional enough, can't convert to different formats easily - CONGLOMERATE: This could be our answer - an XML-based Document editing/management system, FREE (GPL'd); not yet completed... (www.conglomerate.org) I thing Conglomerate could be our solution. But for now, let's bump heads and work together, and put reality back into check. Eron Lloyd

5 6

Object ownership
by Ross Boylan 13 Dec '99

13 Dec '99

I've been making some assumptions about how ownership works, and I'd appreciate it if anyone could tell me if they are right. 1) The owner of an object is the authenticated user when the script that creates it runs. 2) So User objects have an owner of superuser, not themselves. 3) I can programmatically create an object graph, and the ownership of the parts of the graph will be right. 2) is an implication of 1), but seems a bit odd. Thanks.

2 2

fastcgi support: breaks when too many requests come in at once?
by Anthony Baxter 13 Dec '99

13 Dec '99

I'm seeing zope crash when in fastcgi mode when multiple pages are requested in quick succession (e.g. loading a frame). Annoyingly, it won't fail when apache+mod_fcgi, zserver, and the client browser are all on the same local piece of wire, but will fail when there's a pacific ocean between the client and the apache. I haven't tried digging into it too far (yet) but is anyone else out there running a similar configuration? The zope process just silently restarts. The apache+fcgi reports back 'end of headers after 0 bytes'. Getting the individual pages manually works fine. Any ideas? Anthony

1 0

exporting of versions.
by Anthony Baxter 13 Dec '99

13 Dec '99

Continuing from the earlier discussions of production.vs.development machines, has anyone looked at allowing the export of the files modified by a Version? Say I have two Zope installations, dev and prod. Initially I sync them up, then I want to make changes to some of dev, and export the changes over to prod. Right now, the only real way to do that is to manually export the individual objects, or else copy the entire Data.fs file (well, ok, you could also use dd or something to just clip the new Data.fs entries from the end of the file on dev, and concatenate them onto prod's file, but that's a bit disgusting.) One thing that Would Be Neat(tm) would be if you could go to the Version's management screen on dev, then export just the changed objects. You could then go across to the prod machine, and import this file to load up the changed objects. Good idea? Bad idea? Anthony

1 0

FW: [Zope] Zope stability
by Alexander Limi 13 Dec '99

13 Dec '99

Sorry, I had a spelling error in the mail-address to the dev. list, so this never showed up. I think some of the points detailed could be interesting for the next version of Zope. Alexander Limi http://mp3.no > > Also, on a side note, is there a way to do offline development of Zope, and > > commit those changes to the main site at a later date? I know this raises > > important concurrency concerns, but has it ever been considered as a part > > of Zope's feature set? A CVS of sorts, where you check out and in files? > > Well, you can run a developoment server with an identical environmen. To > update the live site, you export the relevant parts, and import them > into the production server. This simply won't work, as we have users from everywhere that want to do changes 24/7. So the main site can't be updated from a production site, because users change the main site all the time. So unless one can update selected parts in a satisfactory way (by exporting only the relevant changes) this is no option. And I can imagine it would get messy, as one had to manually keep track of what changes are made to the test server, export those bits, and then import them on the production server. Would it be an idea to implement this in an easy-to-use way in Zope 2.2? To be able to create a "diff-file" of sorts, that can be exported into the main site, and exclude certain hierarchies, like the ones the users access? While we're at it, my own wishlist for the next version: - Better handling of inheritance in ZClasses, see my earlier post (ZClasses, inheritance & stuff, on the zope(a)zope.org list) (Basically, the ability to use superclasses effectively) - Zope should produce html/dtml in compliance with w3.org's recommendations: in all lowercase - Access to the built-in debug screens from the contol panel (in production mode or not) - An option to turn on "open in new window" as default when using the preview mode (I know, mozilla and all, but as a stop-gap solution until mozilla is stable enough to use :) (small changes that would make me happy, except for the inheritance bit, which may be more time-consuming to implement) Alexander Limi http://mp3.no

2 1