[If this is a known topic please point me to the right thing to search for in the archives]. I've been having some strange intermittent problems with Netscape and the POST method -- never really reproducible and most annoying. The other day I was trying to chase them with Shanes tcpwatch (as a change from ethereal) and I noticed tcpwatch suffering from the same problems. Aha!! To be specific: on occasion the data for a POST transaction was not showing on the display. This matches the problem I've been having with N'scape & Zope: sometimes a POST transaction would just kind of hang. I'm beginning to think that I've traced this down to N'scape not putting any form of terminator after the POST data string -- this appears to mean that the data gets caught in the input collection scheme of asynchat and doesn't get passed up to the next layer for processing until later (if any further traffic occurs on that connection) or never (if the client starts a new connection for the next request). I'm no guru on the http protocol specs. -- can anyone tell whether terminators are required (counted in the content-size header of course) or not. I couldn't find a statement to this effect. If they aren't required (and stherefore ome clients may not send them) how is Zope supposed to deal with this? Is the length from the content-size header somehow fed forward -- once the header has been received of course -- into the asynchat buffering logic so that it can know when to pass the current 'bag of bytes' up to the application layer? Or does the mechanism quietly assume a sufficient density of terminators (which seem to trigger an end of the buffering). Is there a timeout somewhere in there? I'm planning a session of looking through the code to check this out but it's sort of a complex area and I'm looking for a head start to save time, if anyone has already traveled this route. Alos, as it doesn't seem to be reproducible, does anyone know of documented behaviours of browers in this area? To be absolutely fair, this particular (bad) occurence involves the Flash plugin too (which probably means it's M'medias fault); but I have seen it in the past without Flash involvement, and there seems to be a constant level of moaning about Netscape oddities here too. Thanks in advance, Nigel.