Tim Sneddon's VMS fix for huge HTTP POSTs

This commit is contained in:
Daniel Stenberg 2004-11-05 14:43:35 +00:00
parent f10985fc50
commit 6b49fd7483
6 changed files with 43 additions and 5 deletions

View file

@ -1925,14 +1925,15 @@ CURLcode Curl_http(struct connectdata *conn)
if(data->set.postfields) {
if((data->state.authhost.done || data->state.authproxy.done )
&& (postsize < (100*1024))) {
&& (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 100K, 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. */
/* 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. */
result = add_buffer(req_buffer, "\r\n", 2); /* end of headers! */
if(result)

View file

@ -57,5 +57,14 @@ int Curl_http_should_fail(struct connectdata *conn);
public curl/curl.h header. */
#define CURLAUTH_PICKNONE (1<<30) /* don't use auth */
/* MAX_INITIAL_POST_SIZE indicates the number of kilobytes that will be sent
in the initial part of a multi-part POST message. This is primarily for
OpenVMS where the maximum number of bytes allowed per I/O is 64K. For
other systems that do not define this, the default is (as it was
previously) 100K. */
#ifndef MAX_INITIAL_POST_SIZE
#define MAX_INITIAL_POST_SIZE (100*1024)
#endif
#endif
#endif