Description: ------------ The RFC2616 specifies the following: Request = Request-Line ; Section 5.1 *(( general-header ; Section 4.5 | request-header ; Section 5.3 | entity-header ) CRLF) ; Section 7.1 CRLF [ message-body ] ; Section 4.3 So when there is message-body (eg: POST data) there is no need of final CRLF. Btw many simple clients doesn't add that extra CRLF hanging the connection. I'd change in Server.php::__construct(): from: $this->_driver->readEndCharacter = "\r\n\r\n"; to: $this->_driver->readEndCharacter = null; Tomas V.V.Cox

This is a known problem, and we're currently trying to find a solution which allows us to use the "Content-Length" information without making the Net_Server class too HTTP-specific. Maybe you have an idea.

There is no need to touch Net_Server, the change is only at HTTP/Server.php. I'm not very sure on relaying in Content-Length.

Oh sorry, I missunderstand your answer. What about instead of passing the whole request to onReceiveData(), create another method like onReceiveStreamData() letting the subclass the work of readFromSocket(). This would solve the problem of storing big posted files in memory (and will extend the functionality of the class btw). The same would be nice for sending data (streaming video, transferring big files, etc). Tomas V.V.Cox

This seems to be a good idea, we'll have to move this bug over to Net_Server, if Christian agrees.

Hi: Two things about readFromSocket and readEndCharacter: A) I think your last change to readFromSocket (removing the break trim condition) was an error. I'm using my onwn readEndCharacter in sequential driver for detecting end of transmision but I want the protocol to be as safe as possible in case of malformed client request data. After some tests I have found that is very dificult to implement this when the protocol expects the client and the server to alternate in write and reads without timeouts. If the client sends a malformed request, ends socket_write and then waits for reading from socket, the server will wait forever in the next iteration of socket_read. The only way to unblock the server is to end the client (or close the socket) manualy or after a timeout. When the client closes the socket the server exits form socket_read and: - if you keep the "if(trim($buf)) break" then will exit from readFromSocket an all will be ok. - But if there's no check the server will be keept in an infinite loop (while true) making imposible another conection. B) I think your test for detecting the end character: $endString = substr($buf, - strlen($this->readEndCharacter)); if ($endString == $this->readEndCharacter) { break; } would be more secure if you do substr from $data and not from $buf since the encharacter could have come in two separate iterations. Yes I know this is not very likely to happen but CAN happen with large endcharacter (like the one we use) Many thanks for the grat package. You have saved me a lot of time ;-) Javier Lafuente

This is in fact a bug in Net_Server and the fix is REAL simple. I've been fighting with it for a while and found the issue.. The issue is if the "4 character" EndCharacter for HTTP is split across two buff reads. (ie 1 byte in the previous 128 byte read and the last 3 in the next). the SOLUTION is to do the substr on $data instead of $buf. --- Driver.php.orig 2005-11-30 15:57:44.000000000 -0500 +++ Driver.php 2005-11-30 15:59:39.000000000 -0500 @@ -200,8 +200,8 @@ $data .= $buf; if ($this->readEndCharacter != null) { - $endString = substr($buf, - strlen($this->readEndCharacter)); - if ($endString == $this->readEndCharacter) { + $endString = substr($data, - strlen($this->readEndCharacter)); + if ($endString == $this->readEndCharacter || strlen($buf)==0) { break; } } else {

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.