On Mon, 2009-09-21 at 14:46 -0400, Raymond Dans wrote: > 2. HttpServer only solution: Add a check in the read to detect a 0 byte > read return value and not proceed to pass the request to supervisor for > processing. Problem with this solution is that there are other cases > where 0 bytes can be returned (without closing the socket) and we should > send a response back indicating an error in the request. > > 3. HttpMessage/HttpServer solution: Modify HttpMessage to NOT close the > socket in the case of exceeding the maximum content length but return > some error value (< 0). Modify HttpServer to detect the error on the > HttpMessage read and construct an appropriate response that is then > returned. > > 4. HttpServer-2 solution: Same as #2 but also add a check to see if the > socket is still open. If not, don't send a response back at all.
It's clear that we need a better strategy if a malformed XML-RPC is received. (1) At the least, if HttpServer attempts to send a response and the socket is closed, it should not cause a core dump. (2) If the incoming message to HttpServer is malformed to the point that we cannot clearly identify the end of the message (and thus the beginning of the next one), we should close the socket. (3) I'm not sure what processing should be done in the XMLRPC context if a malformed request is received. > 5. sipXconfig solution: Instead of sending extremely large replications > in 1 request, break them up into smaller chunks and use the appropriate > XML-RPC method that adds the records to an IMDB as opposed to calling > the method (replace) which clears the existing IMDB and then adds all of > the records (this of course assumes that all records are in the > request). We will need to do something like that if we are to handle a large number of users. But I think the problem is probably worse that what you describe -- sending many users in small chunks will leave a long time when most of the users are not in the target IMDB. It would be better to either (1) assemble the entire set of users in a temporary space at the destination, then use a quick operation to replace the IMDB contents, or (2) in some manner, send the deltas between the current IMDB and the desired IMDB, and apply them through inserts/deletes, rather than mass-delete followed by mass-insert. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
