This fixes bug http://code.google.com/p/chromium/issues/detail?id=4076, which was a hang while loading certain PDF files. This was a regression caused by support for NPN_RequestRead (PDF Fast Webview). We had incorrectly assumed that the Content Type showing up for partial HTTP Responses would always end with the boundary. A content type can show up like multipart/byteranges; boundary=--bound--; charSet=utf8. As a result we would look for the wrong boundary in the actual data resulting in a hang.

The parsing code now accounts for this. Added a unit test to test this case.

Bug=4076
R=jam


Review URL: http://codereview.chromium.org/9198

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4842 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 6 insertions, 1 deletions

diff --git a/webkit/glue/multipart_response_delegate.cc b/webkit/glue/multipart_response_delegate.cc
index 72d4158..2c2b2b3 100644
--- a/webkit/glue/multipart_response_delegate.cc
+++ b/webkit/glue/multipart_response_delegate.cc
@@ -247,7 +247,12 @@ bool MultipartResponseDelegate::ReadMultipartBoundary(
   }
 
   boundary_start_offset += strlen("boundary=");
-  size_t boundary_end_offset = content_type.length();
+
+  size_t boundary_end_offset =
+      content_type_as_string.find(';', boundary_start_offset);
+
+  if (boundary_end_offset == std::string::npos)
+    boundary_end_offset = content_type_as_string.length(); 
 
   size_t boundary_length = boundary_end_offset - boundary_start_offset;