--Boundary-00=_diUQM/mvU0uFm4c Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The attached patch makes it possible for HTTPProtocol::readBuffered function to behaves differently when called from readLimited. This patch is intended to address the issue of the Gmail chat functionality no longer working in kdewebkit based browsers. Though the patch fully addresses the aforementioned bug, it really does not fix the actual cause of this bug. So what is the actual cause ? Well when you log in to Gmail, a check is preformed to see if the chat functionality is enabled or not. This is done through a simple GET request that returns a 20 byte response. At that point kio_http has read the header and few bytes of the content as well, 3 bytes to be exact. kio_http stores these few bytes of data that are not part of the header in a buffer. It then attempts to read the content and that is where the fun starts... Because kio_http has received the actual size of the content it is supposed to read, it will use readLimited to get the content. readLimited in turn calls readBuffered which, as a result of a fix for bug 180631, always sends whatever data was read ahead while retrieving the header above. This means the 3 bytes above will be sent to the client first in our case. After that kio_http retrieves and attempts to send the remaining 17 bytes. However, this last portion never ever makes it to the client application. It seems to disappear into the ether! Actually it never gets past KIO::Connection::send and at this point I cannot figure out why! So why this patch then ? Simple. If you followed what I attempted to explain above, you would see that it is very inefficient for kio_http to split a 20 byte data especially when it already knows the final size of the content it is supposed to retrieve from the server ; so addressing that through this patch should be no brainer. The fact that the Gmail chat issue gets fixed as a result is only a bonus at this point. And hence my request... #1. Can someone using KHTML verify whether or not the Gmail chat functionality works for them ? I cannot get Gmail to work with KHTML here ; so I am unable to do this myself. #2. Can someone tell me if there is a scenario where sending two MSG_DATA requests in rapid succession might result in one of them being dropped ? #3. Any objections, concerns, suggestions etc about the patch are welcome. Regards, Dawit A. --Boundary-00=_diUQM/mvU0uFm4c Content-Type: text/x-patch; charset="UTF-8"; name="kio_http.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kio_http.patch" Index: http.cpp =================================================================== --- http.cpp (revision 1150888) +++ http.cpp (working copy) @@ -1975,7 +1975,7 @@ } } -size_t HTTPProtocol::readBuffered(char *buf, size_t size) +size_t HTTPProtocol::readBuffered(char *buf, size_t size, bool unlimited) { size_t bytesRead = 0; if (!m_unreadBuf.isEmpty()) { @@ -1987,9 +1987,12 @@ } m_unreadBuf.truncate(bufSize - bytesRead); - // if we have an unread buffer, return here, since we may already have enough data to - // complete the response, so we don't want to wait for more. - return bytesRead; + // If we have an unread buffer and the size of the content returned by the + // server is unknown, e.g. chuncked data, return the bytes read here since + // we may already have enough data to to complete the response and we don't + // need to wait for more. See BR# 180631. + if (unlimited) + return bytesRead; } if (bytesRead < size) { int rawRead = TCPSlaveBase::read(buf + bytesRead, size - bytesRead); Index: http.h =================================================================== --- http.h (revision 1150888) +++ http.h (working copy) @@ -501,7 +501,7 @@ QByteArray m_unreadBuf; void clearUnreadBuffer(); void unread(char *buf, size_t size); - size_t readBuffered(char *buf, size_t size); + size_t readBuffered(char *buf, size_t size, bool unlimited = true); bool readDelimitedText(char *buf, int *idx, int end, int numNewlines); }; #endif --Boundary-00=_diUQM/mvU0uFm4c--