From: Andrew Biggs <adb_at_cisco.com>
Date: Tue, 08 Aug 2006 18:10:11 -0600

I changed the "state" to "set", which solves the problem for when the Expect header is turned off.  Though now I'm noticing that the contents are being sent immediately even when the "Expect: 100-continue" header is on :-/.  Here's the trace:

 * About to connect() to 10.94.248.184 port 80
*   Trying 10.94.248.184... * connected
* Connected to 10.94.248.184 (10.94.248.184) port 80
* Server auth using Basic with user 'aspen\cucsvc'
> PROPPATCH /exchange/ut_cugal0/Calendar/portingcugal.eml HTTP/1.1
Authorization: Basic YXNwZW5cY3Vjc3ZjOkJvdWxkM3I=
Host: 10.94.248.184
Accept: text/xml
Depth: infinity
Connection: Keep-Alive
Content-Type: text/xml
Content-Length: 1445
Expect: 100-continue

<?xml version="1.0"?>
<g:propertyupdate xmlns:g="DAV:"
    xmlns:e="http://schemas.microsoft.com/exchange/"
    xmlns:mapi="http://schemas.microsoft.com/mapi/"
    xmlns:mapit="http://schemas.microsoft.com/mapi/proptag/"
    xmlns:x="xml:" xmlns:cal="urn:schemas:calendar:"
    xmlns:dt="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/"
    xmlns:header="urn:schemas:mailheader:"
    xmlns:mail="urn:schemas:httpmail:">
    <g:set>
        <g:prop>
            <g:contentclass>urn:content-classes:appointment</g:contentclass>
            <e:outlookmessageclass>IPM.Appointment</e:outlookmessageclass>
            <cal:instancetype dt:dt='int'>0</cal:instancetype>
            <header:to>ut_cugal0</header:to>
            <cal:alldayevent dt:dt='boolean'>0</cal:alldayevent>
            <mapi:finvited>1</mapi:finvited>
            <cal:responserequested dt:dt='boolean'>1</cal:responserequested>
            <cal:busystatus>BUSY</cal:busystatus>
            <cal:meetingstatus>CONFIRMED</cal:meetingstatus>
            <cal:location>Longs Peak, Boulder</cal:location>
            <mail:subject>Porting CuGal to Linux</mail:subject>
            <mail:htmldescription>Discussion of performance improvements</mail:htmldescription>
            <cal:dtstart dt:dt='dateTime.tz'>2006-08-09T12:00:00.000Z</cal:dtstart>
            <cal:dtend dt:dt='dateTime.tz'>2006-08-09T12:30:00.000Z</cal:dtend>
        </g:prop>
    </g:set>
</g:propertyupdate>

< HTTP/1.1 207 Multi-Status
< Date: Wed, 09 Aug 2006 00:05:26 GMT
< Server: Microsoft-IIS/6.0
< X-Powered-By: ASP.NET
< MS-Exchange-Permanent-URL: http://10.94.248.184/exchange/ut_cugal0/-FlatUrlSpace-/5d807cc696502c4a9a1ad8e35ff3e326-8114/5d807cc696502c4a9a1ad8e35ff3e326-8451
< Repl-UID: <rid:5d807cc696502c4a9a1ad8e35ff3e326000000008451>
< Content-Type: text/xml
< Content-Length: 660
< ResourceTag: <rt:5d807cc696502c4a9a1ad8e35ff3e3260000000084515d807cc696502c4a9a1ad8e35ff3e32600000000c74d>
< MS-WebStorage: 6.5.6944
* Connection #0 to host 10.94.248.184 left intact

I'm fine with the mod since it solves my problem ;-), but I suspect those who want the "Expect 100-continue" behavior may get broken by it.

Andrew


Andrew Biggs wrote:

Should the lines on 2200 and 2204 be

data->state.expect100header

or

data->set.expect100header

?

Daniel Stenberg wrote:

On Tue, 8 Aug 2006, Andrew Biggs wrote:

At the moment I'm just relying on the output from having set
CURLOPT_VERBOSE, but I could set up Ethereal and confirm if you think

Would you be able to check if the attached patch makes it work more in the way you'd expect it?

Index: lib/http.c
===================================================================
RCS file: /cvsroot/curl/curl/lib/http.c,v
retrieving revision 1.288
diff -u -r1.288 http.c
--- lib/http.c	8 Aug 2006 21:12:50 -0000	1.288
+++ lib/http.c	8 Aug 2006 23:17:13 -0000
@@ -2247,18 +2247,29 @@
           return result;
       }
 
+
       if(data->set.postfields) {
 
-        if((data->state.authhost.done || data->state.authproxy.done )
-           && (postsize < MAX_INITIAL_POST_SIZE)) {
-          /* If we're not done with the authentication phase, we don't expect
-             to actually send off any data yet. Hence, we delay the sending of
-             the body until we receive that friendly 100-continue response */
-
-          /* The post data is less than MAX_INITIAL_PORT_SIZE, then append it
-             to the header. This limit is no magic limit but only set to
-             prevent really huge POSTs to get the data duplicated with
-             malloc() and family. */
+        if(postsize > TINY_INITIAL_POST_SIZE) {
+          result = expect100(data, req_buffer);
+          if(result)
+            return result;
+        }
+        else
+          data->state.expect100header = FALSE;
+
+        if(((data->state.authhost.done && data->state.authproxy.done ) ||
+            (postsize < TINY_INITIAL_POST_SIZE) ||
+            !data->state.expect100header) &&
+           postsize < MAX_INITIAL_POST_SIZE)  {
+          /* [ If we're done with the authentication phase or
+             if the postsize is tiny or
+             we don't expect:-100 ] AND
+             postsize is less than MAX_INITIAL_POST_SIZE
+
+             then append the post data to the HTTP request header. This limit
+             is no magic limit but only set to prevent really huge POSTs to
+             get the data duplicated with malloc() and family. */
 
           result = add_buffer(req_buffer, "\r\n", 2); /* end of headers! */
           if(result)
@@ -2297,18 +2308,10 @@
           /* set the upload size to the progress meter */
           Curl_pgrsSetUploadSize(data, http->postsize);
 
-          result = expect100(data, req_buffer);
-          if(result)
-            return result;
-
           add_buffer(req_buffer, "\r\n", 2); /* end of headers! */
         }
       }
       else {
-        result = expect100(data, req_buffer);
-        if(result)
-          return result;
-
         add_buffer(req_buffer, "\r\n", 2); /* end of headers! */
 
         if(data->set.postfieldsize) {
Index: lib/http.h
===================================================================
RCS file: /cvsroot/curl/curl/lib/http.h,v
retrieving revision 1.30
diff -u -r1.30 http.h
--- lib/http.h	10 Apr 2006 15:00:54 -0000	1.30
+++ lib/http.h	8 Aug 2006 23:17:13 -0000
@@ -74,7 +74,11 @@
    It must not be greater than 64K to work on VMS.
 */
 #ifndef MAX_INITIAL_POST_SIZE
-#define MAX_INITIAL_POST_SIZE 1024
+#define MAX_INITIAL_POST_SIZE (64*1024)
+#endif
+
+#ifndef TINY_INITIAL_POST_SIZE
+#define TINY_INITIAL_POST_SIZE 1024
 #endif
 
 #endif
  

Received on 2006-08-09