[prev in list] [next in list] [prev in thread] [next in thread] 

List:       konq-bugs
Subject:    [Bug 180631] Extremely long load time on www.abclinuxu.cz
From:       Maksim Orlovich <maksim () kde ! org>
Date:       2009-01-31 22:27:33
Message-ID: 20090131222733.80B3F12B33 () immanuel ! kde ! org
[Download RAW message or body]

http://bugs.kde.org/show_bug.cgi?id=180631





--- Comment #5 from Maksim Orlovich <maksim kde org>  2009-01-31 23:27:32 ---
Potential fix below. The problem seems to occur because we get the 304 response
+ headers in the single read. Then, we parse the response, unget the headers,
and then when trying to get the headers next do a blocking read. This make it
return unget buffer first:

Index: http.cpp
===================================================================
--- http.cpp    (revision 919318)
+++ http.cpp    (working copy)
@@ -1861,6 +1861,8 @@
     m_unreadBuf.clear();
 }

+// Note: the implementation of unread/readBuffered assumes that unread will
only 
+// be used when there is extra data we don't want to handle, and not to wait
for more data.
 void HTTPProtocol::unread(char *buf, size_t size)
 {
     // implement LIFO (stack) semantics
@@ -1886,6 +1888,10 @@
             buf[i] = m_unreadBuf.constData()[bufSize - i - 1];
         }
         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 (bytesRead < size) {
         int rawRead = TCPSlaveBase::read(buf + bytesRead, size - bytesRead);


-- 
Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Konq-bugs mailing list
Konq-bugs@mail.kde.org
https://mail.kde.org/mailman/listinfo/konq-bugs
[prev in list] [next in list] [prev in thread] [next in thread]