[Zope] asynchat usage in Zope & terminators? (not short!)

[Nigel Head]

[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.