[This message is a followup to a thread started by my original post regarding the performance of the server provided by the Apache XML-RPC Project (formerly the from Helma).]
Timothy Peierls <[EMAIL PROTECTED]> writes: > The spec is not exactly clear about whether comments and PIs > are allowed, so you can be sure that there is or will be an > implementation out there that uses a trailing PI to send > sideband information for clients that care about it, leaving > other clients to ignore it. Innocent clients that rely on the > document close tag will break, and the rogue implementation > author can claim with some justification that the spec doesn't > disallow the trailing PIs. So clients cannot in general use > the closing tag in lieu of the Content-length. > > At any rate, there seems to be general agreement that servers > can't omit the Content-length header, so ultimately, yes, the > point is moot. The XML-RPC spec apparently does not take HTTP/1.1 into consideration (I believe it came while HTTP/1.1 was still an emergent technology when the spec was published). http://www.w3.org/Protocols/rfc2616/rfc2616.html I spoke with Greg Stein about how Apache httpd handles large responses (hopefully I don't misrepresent what he said here too badly ;-). httpd apprently writes the Content-Length header if the response is smaller than a certain threshold. If the response size exceeds this threshold, one of two things happens based on the client's HTTP protocol support. If the client does not support HTTP/1.1, the Content-Length header is omitted and the response is streamed to the client, terminated by the close of the socket connection (ignoring Keep-Alive headers because of the great size of the response). If HTTP/1.1 is supported, Chunked Transfer Coding is used (see RFC 2616, section 3.6.1): "All HTTP/1.1 applications MUST be able to receive and decode the 'chunked' transfer-coding, [...]" When chunking, the server says it's sending X bytes, dump X bytes to the response stream, and repeats as necessary. I would assume that Keep-Alives would work in this situation, since there would be no need to close the socket to signal end of stream. This nicely reduces the size of the RAM buffers necessary for sending large responses. Section 4.4 (Message Length) provides a nice summary of implementation requirements. I think the spec needs adjustment for HTTP/1.1, so I'm CC'ing this mail to UserLand (as they appear to maintain the XML-RPC spec). If no one has any issues with it, I will also be so bold as to create a branch in the CVS repository for adding HTTP/1.1 support to the client and server, banking on the eventuality of spec support. Thanks, Dan
