2002-09-03 19:52:59 +08:00
|
|
|
/***************************************************************************
|
2004-05-17 14:50:08 +08:00
|
|
|
* _ _ ____ _
|
|
|
|
* Project ___| | | | _ \| |
|
|
|
|
* / __| | | | |_) | |
|
|
|
|
* | (__| |_| | _ <| |___
|
2000-05-22 22:09:31 +08:00
|
|
|
* \___|\___/|_| \_\_____|
|
|
|
|
*
|
2023-01-02 20:51:48 +08:00
|
|
|
* Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
2000-05-22 22:09:31 +08:00
|
|
|
*
|
2002-09-03 19:52:59 +08:00
|
|
|
* This software is licensed as described in the file COPYING, which
|
|
|
|
* you should have received as part of this distribution. The terms
|
2020-11-04 21:02:01 +08:00
|
|
|
* are also available at https://curl.se/docs/copyright.html.
|
2004-05-17 14:50:08 +08:00
|
|
|
*
|
2001-01-03 17:29:33 +08:00
|
|
|
* You may opt to use, copy, modify, merge, publish, distribute and/or sell
|
|
|
|
* copies of the Software, and permit persons to whom the Software is
|
2002-09-03 19:52:59 +08:00
|
|
|
* furnished to do so, under the terms of the COPYING file.
|
2000-05-22 22:09:31 +08:00
|
|
|
*
|
2001-01-03 17:29:33 +08:00
|
|
|
* This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY
|
|
|
|
* KIND, either express or implied.
|
2000-05-22 22:09:31 +08:00
|
|
|
*
|
2010-12-21 05:17:41 +08:00
|
|
|
* SPDX-License-Identifier: curl
|
2022-05-17 17:16:50 +08:00
|
|
|
*
|
2002-09-03 19:52:59 +08:00
|
|
|
***************************************************************************/
|
2000-05-22 22:09:31 +08:00
|
|
|
|
2013-01-07 02:06:49 +08:00
|
|
|
#include "curl_setup.h"
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "strtoofft.h"
|
2000-05-22 22:09:31 +08:00
|
|
|
|
2004-02-02 22:49:54 +08:00
|
|
|
#ifdef HAVE_NETINET_IN_H
|
2000-05-22 22:09:31 +08:00
|
|
|
#include <netinet/in.h>
|
2004-02-02 22:49:54 +08:00
|
|
|
#endif
|
2007-04-04 04:54:37 +08:00
|
|
|
#ifdef HAVE_NETDB_H
|
2000-05-22 22:09:31 +08:00
|
|
|
#include <netdb.h>
|
2007-04-04 04:54:37 +08:00
|
|
|
#endif
|
2000-05-22 22:09:31 +08:00
|
|
|
#ifdef HAVE_ARPA_INET_H
|
|
|
|
#include <arpa/inet.h>
|
|
|
|
#endif
|
|
|
|
#ifdef HAVE_NET_IF_H
|
|
|
|
#include <net/if.h>
|
|
|
|
#endif
|
2004-02-02 22:49:54 +08:00
|
|
|
#ifdef HAVE_SYS_IOCTL_H
|
2000-05-22 22:09:31 +08:00
|
|
|
#include <sys/ioctl.h>
|
2004-02-02 22:49:54 +08:00
|
|
|
#endif
|
2000-05-22 22:09:31 +08:00
|
|
|
#include <signal.h>
|
|
|
|
|
|
|
|
#ifdef HAVE_SYS_PARAM_H
|
|
|
|
#include <sys/param.h>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef HAVE_SYS_SELECT_H
|
|
|
|
#include <sys/select.h>
|
2020-03-30 21:52:43 +08:00
|
|
|
#elif defined(HAVE_UNISTD_H)
|
|
|
|
#include <unistd.h>
|
2000-05-22 22:09:31 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef HAVE_SOCKET
|
2024-07-01 22:47:21 +08:00
|
|
|
#error "We cannot compile without socket() support!"
|
2000-05-22 22:09:31 +08:00
|
|
|
#endif
|
|
|
|
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "urldata.h"
|
2000-05-22 22:09:31 +08:00
|
|
|
#include <curl/curl.h>
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "netrc.h"
|
|
|
|
|
|
|
|
#include "content_encoding.h"
|
|
|
|
#include "hostip.h"
|
2022-11-11 18:45:34 +08:00
|
|
|
#include "cfilters.h"
|
2024-02-07 19:05:05 +08:00
|
|
|
#include "cw-out.h"
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "transfer.h"
|
|
|
|
#include "sendf.h"
|
|
|
|
#include "speedcheck.h"
|
|
|
|
#include "progress.h"
|
|
|
|
#include "http.h"
|
|
|
|
#include "url.h"
|
|
|
|
#include "getinfo.h"
|
2013-12-18 06:32:47 +08:00
|
|
|
#include "vtls/vtls.h"
|
2022-12-30 16:14:55 +08:00
|
|
|
#include "vquic/vquic.h"
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "select.h"
|
|
|
|
#include "multiif.h"
|
|
|
|
#include "connect.h"
|
2016-09-05 17:07:40 +08:00
|
|
|
#include "http2.h"
|
2017-09-03 00:47:10 +08:00
|
|
|
#include "mime.h"
|
2017-09-08 21:13:42 +08:00
|
|
|
#include "strcase.h"
|
2018-08-05 17:51:07 +08:00
|
|
|
#include "urlapi-int.h"
|
2020-11-03 06:17:01 +08:00
|
|
|
#include "hsts.h"
|
2021-02-12 17:27:42 +08:00
|
|
|
#include "setopt.h"
|
2022-03-17 17:20:19 +08:00
|
|
|
#include "headers.h"
|
2000-05-22 22:09:31 +08:00
|
|
|
|
2016-04-29 21:46:40 +08:00
|
|
|
/* The last 3 #include files should be in this order */
|
|
|
|
#include "curl_printf.h"
|
2015-03-25 06:12:03 +08:00
|
|
|
#include "curl_memory.h"
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "memdebug.h"
|
2000-10-09 19:12:34 +08:00
|
|
|
|
2017-09-08 21:13:42 +08:00
|
|
|
#if !defined(CURL_DISABLE_HTTP) || !defined(CURL_DISABLE_SMTP) || \
|
|
|
|
!defined(CURL_DISABLE_IMAP)
|
|
|
|
/*
|
|
|
|
* checkheaders() checks the linked list of custom headers for a
|
2018-03-06 06:38:16 +08:00
|
|
|
* particular header (prefix). Provide the prefix without colon!
|
2017-09-08 21:13:42 +08:00
|
|
|
*
|
|
|
|
* Returns a pointer to the first matching header or NULL if none matched.
|
|
|
|
*/
|
2021-01-09 00:58:15 +08:00
|
|
|
char *Curl_checkheaders(const struct Curl_easy *data,
|
2022-02-09 07:57:00 +08:00
|
|
|
const char *thisheader,
|
|
|
|
const size_t thislen)
|
2017-09-08 21:13:42 +08:00
|
|
|
{
|
|
|
|
struct curl_slist *head;
|
2021-05-02 05:38:15 +08:00
|
|
|
DEBUGASSERT(thislen);
|
|
|
|
DEBUGASSERT(thisheader[thislen-1] != ':');
|
2017-09-08 21:13:42 +08:00
|
|
|
|
2017-09-10 05:09:06 +08:00
|
|
|
for(head = data->set.headers; head; head = head->next) {
|
2018-03-06 06:38:16 +08:00
|
|
|
if(strncasecompare(head->data, thisheader, thislen) &&
|
|
|
|
Curl_headersep(head->data[thislen]) )
|
2017-09-08 21:13:42 +08:00
|
|
|
return head->data;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2022-11-22 16:55:41 +08:00
|
|
|
static int data_pending(struct Curl_easy *data)
|
2005-02-10 07:09:12 +08:00
|
|
|
{
|
2019-11-16 15:57:45 +08:00
|
|
|
struct connectdata *conn = data->conn;
|
2020-07-27 21:43:45 +08:00
|
|
|
|
2021-05-15 05:44:07 +08:00
|
|
|
if(conn->handler->protocol&PROTO_FAMILY_FTP)
|
2022-11-22 16:55:41 +08:00
|
|
|
return Curl_conn_data_pending(data, SECONDARYSOCKET);
|
2021-05-15 05:44:07 +08:00
|
|
|
|
2007-04-27 05:30:29 +08:00
|
|
|
/* in the case of libssh2, we can never be really sure that we have emptied
|
|
|
|
its internal buffers so we MUST always try until we get EAGAIN back */
|
2011-03-15 05:52:14 +08:00
|
|
|
return conn->handler->protocol&(CURLPROTO_SCP|CURLPROTO_SFTP) ||
|
2022-11-22 16:55:41 +08:00
|
|
|
Curl_conn_data_pending(data, FIRSTSOCKET);
|
2005-02-10 07:09:12 +08:00
|
|
|
}
|
2004-06-09 16:23:55 +08:00
|
|
|
|
2011-01-30 11:12:33 +08:00
|
|
|
/*
|
|
|
|
* Check to see if CURLOPT_TIMECONDITION was met by comparing the time of the
|
|
|
|
* remote document with the time provided by CURLOPT_TIMEVAL
|
|
|
|
*/
|
2016-06-21 21:47:12 +08:00
|
|
|
bool Curl_meets_timecondition(struct Curl_easy *data, time_t timeofdoc)
|
2011-01-30 11:12:33 +08:00
|
|
|
{
|
|
|
|
if((timeofdoc == 0) || (data->set.timevalue == 0))
|
|
|
|
return TRUE;
|
|
|
|
|
|
|
|
switch(data->set.timecondition) {
|
|
|
|
case CURL_TIMECOND_IFMODSINCE:
|
|
|
|
default:
|
|
|
|
if(timeofdoc <= data->set.timevalue) {
|
|
|
|
infof(data,
|
2021-07-06 23:05:17 +08:00
|
|
|
"The requested document is not new enough");
|
2011-01-30 11:12:33 +08:00
|
|
|
data->info.timecond = TRUE;
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case CURL_TIMECOND_IFUNMODSINCE:
|
|
|
|
if(timeofdoc >= data->set.timevalue) {
|
|
|
|
infof(data,
|
2021-07-06 23:05:17 +08:00
|
|
|
"The requested document is not old enough");
|
2011-01-30 11:12:33 +08:00
|
|
|
data->info.timecond = TRUE;
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
2008-08-09 04:37:54 +08:00
|
|
|
|
2024-06-10 19:32:13 +08:00
|
|
|
static CURLcode xfer_recv_shutdown(struct Curl_easy *data, bool *done)
|
|
|
|
{
|
|
|
|
int sockindex;
|
|
|
|
|
|
|
|
if(!data || !data->conn)
|
|
|
|
return CURLE_FAILED_INIT;
|
|
|
|
if(data->conn->sockfd == CURL_SOCKET_BAD)
|
|
|
|
return CURLE_FAILED_INIT;
|
|
|
|
sockindex = (data->conn->sockfd == data->conn->sock[SECONDARYSOCKET]);
|
|
|
|
return Curl_conn_shutdown(data, sockindex, done);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool xfer_recv_shutdown_started(struct Curl_easy *data)
|
|
|
|
{
|
|
|
|
int sockindex;
|
|
|
|
|
|
|
|
if(!data || !data->conn)
|
|
|
|
return CURLE_FAILED_INIT;
|
|
|
|
if(data->conn->sockfd == CURL_SOCKET_BAD)
|
|
|
|
return CURLE_FAILED_INIT;
|
|
|
|
sockindex = (data->conn->sockfd == data->conn->sock[SECONDARYSOCKET]);
|
|
|
|
return Curl_shutdown_started(data, sockindex);
|
|
|
|
}
|
|
|
|
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
/**
|
|
|
|
* Receive raw response data for the transfer.
|
|
|
|
* @param data the transfer
|
|
|
|
* @param buf buffer to keep response data received
|
|
|
|
* @param blen length of `buf`
|
|
|
|
* @param eos_reliable if EOS detection in underlying connection is reliable
|
|
|
|
* @param err error code in case of -1 return
|
|
|
|
* @return number of bytes read or -1 for error
|
|
|
|
*/
|
|
|
|
static ssize_t Curl_xfer_recv_resp(struct Curl_easy *data,
|
|
|
|
char *buf, size_t blen,
|
|
|
|
bool eos_reliable,
|
|
|
|
CURLcode *err)
|
|
|
|
{
|
|
|
|
ssize_t nread;
|
|
|
|
|
|
|
|
DEBUGASSERT(blen > 0);
|
|
|
|
/* If we are reading BODY data and the connection does NOT handle EOF
|
|
|
|
* and we know the size of the BODY data, limit the read amount */
|
|
|
|
if(!eos_reliable && !data->req.header && data->req.size != -1) {
|
|
|
|
curl_off_t totalleft = data->req.size - data->req.bytecount;
|
|
|
|
if(totalleft <= 0)
|
|
|
|
blen = 0;
|
|
|
|
else if(totalleft < (curl_off_t)blen)
|
|
|
|
blen = (size_t)totalleft;
|
|
|
|
}
|
2024-06-10 19:32:13 +08:00
|
|
|
else if(xfer_recv_shutdown_started(data)) {
|
|
|
|
/* we already reveived everything. Do not try more. */
|
|
|
|
blen = 0;
|
|
|
|
}
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
|
|
|
|
if(!blen) {
|
2024-06-10 19:32:13 +08:00
|
|
|
/* want nothing more */
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
*err = CURLE_OK;
|
2024-06-10 19:32:13 +08:00
|
|
|
nread = 0;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
*err = Curl_xfer_recv(data, buf, blen, &nread);
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if(*err)
|
|
|
|
return -1;
|
2024-06-10 19:32:13 +08:00
|
|
|
if(nread == 0) {
|
|
|
|
if(data->req.shutdown) {
|
|
|
|
bool done;
|
|
|
|
*err = xfer_recv_shutdown(data, &done);
|
|
|
|
if(*err)
|
|
|
|
return -1;
|
|
|
|
if(!done) {
|
|
|
|
*err = CURLE_AGAIN;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
2024-07-01 22:47:21 +08:00
|
|
|
DEBUGF(infof(data, "readwrite_data: we are done"));
|
2024-06-10 19:32:13 +08:00
|
|
|
}
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
DEBUGASSERT(nread >= 0);
|
|
|
|
return nread;
|
|
|
|
}
|
|
|
|
|
2004-04-26 15:12:52 +08:00
|
|
|
/*
|
2008-08-09 04:37:54 +08:00
|
|
|
* Go ahead and do a read if we have a readable socket or if
|
|
|
|
* the stream was rewound (in which case we have data in a
|
|
|
|
* buffer)
|
2004-04-26 15:12:52 +08:00
|
|
|
*/
|
2016-06-21 21:47:12 +08:00
|
|
|
static CURLcode readwrite_data(struct Curl_easy *data,
|
2008-08-09 04:37:54 +08:00
|
|
|
struct SingleRequest *k,
|
2024-03-11 19:35:07 +08:00
|
|
|
int *didwhat)
|
2000-05-22 22:09:31 +08:00
|
|
|
{
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
struct connectdata *conn = data->conn;
|
2008-08-13 03:09:20 +08:00
|
|
|
CURLcode result = CURLE_OK;
|
2024-01-26 19:05:08 +08:00
|
|
|
char *buf, *xfer_buf;
|
|
|
|
size_t blen, xfer_blen;
|
2023-12-12 02:36:27 +08:00
|
|
|
int maxloops = 10;
|
2023-12-22 19:27:59 +08:00
|
|
|
curl_off_t total_received = 0;
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
bool is_multiplex = FALSE;
|
2004-05-17 14:50:08 +08:00
|
|
|
|
2024-01-26 19:05:08 +08:00
|
|
|
result = Curl_multi_xfer_buf_borrow(data, &xfer_buf, &xfer_blen);
|
|
|
|
if(result)
|
|
|
|
goto out;
|
|
|
|
|
2008-08-09 04:37:54 +08:00
|
|
|
/* This is where we loop until we have read everything there is to
|
2010-05-07 21:05:34 +08:00
|
|
|
read or we get a CURLE_AGAIN */
|
2008-08-09 04:37:54 +08:00
|
|
|
do {
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
bool is_eos = FALSE;
|
|
|
|
size_t bytestoread;
|
|
|
|
ssize_t nread;
|
|
|
|
|
|
|
|
if(!is_multiplex) {
|
|
|
|
/* Multiplexed connection have inherent handling of EOF and we do not
|
|
|
|
* have to carefully restrict the amount we try to read.
|
|
|
|
* Multiplexed changes only in one direction. */
|
|
|
|
is_multiplex = Curl_conn_is_multiplex(conn, FIRSTSOCKET);
|
2023-12-22 19:27:59 +08:00
|
|
|
}
|
|
|
|
|
2024-01-26 19:05:08 +08:00
|
|
|
buf = xfer_buf;
|
|
|
|
bytestoread = xfer_blen;
|
2023-11-07 00:06:06 +08:00
|
|
|
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
if(bytestoread && data->set.max_recv_speed) {
|
2024-03-05 18:08:55 +08:00
|
|
|
/* In case of speed limit on receiving: if this loop already got
|
|
|
|
* data, break out. If not, limit the amount of bytes to receive.
|
|
|
|
* The overall, timed, speed limiting is done in multi.c */
|
|
|
|
if(total_received)
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
break;
|
2024-03-05 18:08:55 +08:00
|
|
|
if((size_t)data->set.max_recv_speed < bytestoread)
|
|
|
|
bytestoread = (size_t)data->set.max_recv_speed;
|
2008-08-09 04:37:54 +08:00
|
|
|
}
|
2007-04-17 00:34:08 +08:00
|
|
|
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
nread = Curl_xfer_recv_resp(data, buf, bytestoread,
|
|
|
|
is_multiplex, &result);
|
|
|
|
if(nread < 0) {
|
2022-11-11 18:45:34 +08:00
|
|
|
if(CURLE_AGAIN == result) {
|
|
|
|
result = CURLE_OK;
|
2009-02-27 16:53:10 +08:00
|
|
|
break; /* get out of loop */
|
2022-11-11 18:45:34 +08:00
|
|
|
}
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
goto out; /* real error */
|
2008-08-09 04:37:54 +08:00
|
|
|
}
|
2007-07-11 06:26:32 +08:00
|
|
|
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
/* We only get a 0-length read on EndOfStream */
|
|
|
|
blen = (size_t)nread;
|
|
|
|
is_eos = (blen == 0);
|
2009-05-11 15:53:38 +08:00
|
|
|
*didwhat |= KEEP_RECV;
|
2023-11-07 00:06:06 +08:00
|
|
|
|
|
|
|
if(!blen) {
|
2022-12-30 16:14:55 +08:00
|
|
|
/* if we receive 0 or less here, either the data transfer is done or the
|
2020-03-18 14:51:55 +08:00
|
|
|
server closed the connection and we bail out from this! */
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
if(is_multiplex)
|
2022-07-08 17:48:09 +08:00
|
|
|
DEBUGF(infof(data, "nread == 0, stream closed, bailing"));
|
|
|
|
else
|
2021-07-06 23:05:17 +08:00
|
|
|
DEBUGF(infof(data, "nread <= 0, server closed connection, bailing"));
|
2024-05-22 22:52:16 +08:00
|
|
|
/* stop receiving and ALL sending as well, including PAUSE and HOLD.
|
|
|
|
* We might still be paused on receive client writes though, so
|
|
|
|
* keep those bits around. */
|
|
|
|
k->keepon &= ~(KEEP_RECV|KEEP_SENDBITS);
|
2024-04-03 19:18:01 +08:00
|
|
|
if(k->eos_written) /* already did write this to client, leave */
|
2023-11-21 18:24:18 +08:00
|
|
|
break;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
total_received += blen;
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2024-03-11 19:35:07 +08:00
|
|
|
result = Curl_xfer_write_resp(data, buf, blen, is_eos);
|
|
|
|
if(result || data->req.done)
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
goto out;
|
2002-12-05 22:26:30 +08:00
|
|
|
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
/* if we are done, we stop receiving. On multiplexed connections,
|
|
|
|
* we should read the EOS. Which may arrive as meta data after
|
|
|
|
* the bytes. Not taking it in might lead to RST of streams. */
|
|
|
|
if((!is_multiplex && data->req.download_done) || is_eos) {
|
|
|
|
data->req.keepon &= ~KEEP_RECV;
|
2008-08-09 04:37:54 +08:00
|
|
|
}
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
/* if we are PAUSEd or stopped receiving, leave the loop */
|
|
|
|
if((k->keepon & KEEP_RECV_PAUSE) || !(k->keepon & KEEP_RECV))
|
2018-11-06 07:29:55 +08:00
|
|
|
break;
|
|
|
|
|
2024-07-04 17:14:05 +08:00
|
|
|
} while(maxloops--);
|
2008-08-09 04:37:54 +08:00
|
|
|
|
2024-06-13 23:02:55 +08:00
|
|
|
if((maxloops <= 0) || data_pending(data)) {
|
|
|
|
/* did not read until EAGAIN or there is still pending data, mark as
|
|
|
|
read-again-please */
|
2023-12-13 18:25:20 +08:00
|
|
|
data->state.select_bits = CURL_CSELECT_IN;
|
2023-12-22 19:27:59 +08:00
|
|
|
if((k->keepon & KEEP_SENDBITS) == KEEP_SEND)
|
|
|
|
data->state.select_bits |= CURL_CSELECT_OUT;
|
2016-08-02 06:48:23 +08:00
|
|
|
}
|
|
|
|
|
2009-05-11 15:53:38 +08:00
|
|
|
if(((k->keepon & (KEEP_RECV|KEEP_SEND)) == KEEP_SEND) &&
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
(conn->bits.close || is_multiplex)) {
|
2024-07-01 22:47:21 +08:00
|
|
|
/* When we have read the entire thing and the close bit is set, the server
|
|
|
|
may now close the connection. If there is now any kind of sending going
|
2008-09-08 15:39:05 +08:00
|
|
|
on from our side, we need to stop that immediately. */
|
2021-07-06 23:05:17 +08:00
|
|
|
infof(data, "we are done reading and this is set to close, stop send");
|
2009-05-11 15:53:38 +08:00
|
|
|
k->keepon &= ~KEEP_SEND; /* no writing anymore either */
|
2023-11-30 04:49:06 +08:00
|
|
|
k->keepon &= ~KEEP_SEND_PAUSE; /* no pausing anymore either */
|
2008-08-29 18:47:59 +08:00
|
|
|
}
|
|
|
|
|
2022-11-11 18:45:34 +08:00
|
|
|
out:
|
2024-01-26 19:05:08 +08:00
|
|
|
Curl_multi_xfer_buf_release(data, xfer_buf);
|
2022-12-30 16:14:55 +08:00
|
|
|
if(result)
|
2023-05-23 18:48:58 +08:00
|
|
|
DEBUGF(infof(data, "readwrite_data() -> %d", result));
|
2022-11-11 18:45:34 +08:00
|
|
|
return result;
|
2008-08-09 04:37:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Send data to upload to the server, when the socket is writable.
|
|
|
|
*/
|
2024-02-28 21:51:53 +08:00
|
|
|
static CURLcode readwrite_upload(struct Curl_easy *data, int *didwhat)
|
2008-08-09 04:37:54 +08:00
|
|
|
{
|
2024-02-28 21:51:53 +08:00
|
|
|
if((data->req.keepon & KEEP_SEND_PAUSE))
|
|
|
|
return CURLE_OK;
|
2000-05-22 22:09:31 +08:00
|
|
|
|
2024-02-28 21:51:53 +08:00
|
|
|
/* We should not get here when the sending is already done. It
|
|
|
|
* probably means that someone set `data-req.keepon |= KEEP_SEND`
|
|
|
|
* when it should not. */
|
|
|
|
DEBUGASSERT(!Curl_req_done_sending(data));
|
2000-05-22 22:09:31 +08:00
|
|
|
|
2024-02-28 21:51:53 +08:00
|
|
|
if(!Curl_req_done_sending(data)) {
|
|
|
|
*didwhat |= KEEP_SEND;
|
2024-05-24 16:09:32 +08:00
|
|
|
return Curl_req_send_more(data);
|
2024-02-28 21:51:53 +08:00
|
|
|
}
|
2024-05-24 16:09:32 +08:00
|
|
|
return CURLE_OK;
|
2008-08-09 04:37:54 +08:00
|
|
|
}
|
2002-01-03 23:01:22 +08:00
|
|
|
|
2023-09-29 20:17:08 +08:00
|
|
|
static int select_bits_paused(struct Curl_easy *data, int select_bits)
|
|
|
|
{
|
|
|
|
/* See issue #11982: we really need to be careful not to progress
|
|
|
|
* a transfer direction when that direction is paused. Not all parts
|
|
|
|
* of our state machine are handling PAUSED transfers correctly. So, we
|
|
|
|
* do not want to go there.
|
|
|
|
* NOTE: we are only interested in PAUSE, not HOLD. */
|
2024-01-22 23:22:19 +08:00
|
|
|
|
|
|
|
/* if there is data in a direction not paused, return false */
|
|
|
|
if(((select_bits & CURL_CSELECT_IN) &&
|
|
|
|
!(data->req.keepon & KEEP_RECV_PAUSE)) ||
|
|
|
|
((select_bits & CURL_CSELECT_OUT) &&
|
|
|
|
!(data->req.keepon & KEEP_SEND_PAUSE)))
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
return (data->req.keepon & (KEEP_RECV_PAUSE|KEEP_SEND_PAUSE));
|
2023-09-29 20:17:08 +08:00
|
|
|
}
|
|
|
|
|
2008-08-09 04:37:54 +08:00
|
|
|
/*
|
|
|
|
* Curl_readwrite() is the low-level function to be called when data is to
|
|
|
|
* be read and written to/from the connection.
|
|
|
|
*/
|
2024-03-11 19:35:07 +08:00
|
|
|
CURLcode Curl_readwrite(struct Curl_easy *data)
|
2008-08-09 04:37:54 +08:00
|
|
|
{
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
struct connectdata *conn = data->conn;
|
2008-08-09 04:37:54 +08:00
|
|
|
struct SingleRequest *k = &data->req;
|
|
|
|
CURLcode result;
|
2023-02-17 19:53:13 +08:00
|
|
|
struct curltime now;
|
2017-09-10 05:09:06 +08:00
|
|
|
int didwhat = 0;
|
2023-04-21 18:04:46 +08:00
|
|
|
int select_bits;
|
2002-03-20 18:53:24 +08:00
|
|
|
|
2023-12-13 18:25:20 +08:00
|
|
|
if(data->state.select_bits) {
|
|
|
|
if(select_bits_paused(data, data->state.select_bits)) {
|
2023-09-29 20:17:08 +08:00
|
|
|
/* leave the bits unchanged, so they'll tell us what to do when
|
|
|
|
* this transfer gets unpaused. */
|
2023-12-13 18:25:20 +08:00
|
|
|
DEBUGF(infof(data, "readwrite, select_bits, early return on PAUSED"));
|
2023-09-29 20:17:08 +08:00
|
|
|
result = CURLE_OK;
|
|
|
|
goto out;
|
|
|
|
}
|
2023-12-13 18:25:20 +08:00
|
|
|
select_bits = data->state.select_bits;
|
|
|
|
data->state.select_bits = 0;
|
2023-04-21 18:04:46 +08:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
curl_socket_t fd_read;
|
|
|
|
curl_socket_t fd_write;
|
|
|
|
/* only use the proper socket if the *_HOLD bit is not set simultaneously
|
|
|
|
as then we are in rate limiting state in that transfer direction */
|
|
|
|
if((k->keepon & KEEP_RECVBITS) == KEEP_RECV)
|
|
|
|
fd_read = conn->sockfd;
|
|
|
|
else
|
|
|
|
fd_read = CURL_SOCKET_BAD;
|
2008-05-09 20:53:42 +08:00
|
|
|
|
2023-02-08 17:26:58 +08:00
|
|
|
if((k->keepon & KEEP_SENDBITS) == KEEP_SEND)
|
2023-04-21 18:04:46 +08:00
|
|
|
fd_write = conn->writesockfd;
|
|
|
|
else
|
|
|
|
fd_write = CURL_SOCKET_BAD;
|
2015-04-30 14:20:49 +08:00
|
|
|
|
2023-04-21 18:04:46 +08:00
|
|
|
select_bits = Curl_socket_check(fd_read, CURL_SOCKET_BAD, fd_write, 0);
|
|
|
|
}
|
2008-05-09 20:53:42 +08:00
|
|
|
|
2023-04-21 18:04:46 +08:00
|
|
|
if(select_bits == CURL_CSELECT_ERR) {
|
2008-08-09 04:37:54 +08:00
|
|
|
failf(data, "select/poll returned error");
|
2022-11-11 18:45:34 +08:00
|
|
|
result = CURLE_SEND_ERROR;
|
|
|
|
goto out;
|
2008-08-09 04:37:54 +08:00
|
|
|
}
|
2008-05-09 20:53:42 +08:00
|
|
|
|
2020-12-14 21:10:33 +08:00
|
|
|
#ifdef USE_HYPER
|
2021-05-31 21:11:27 +08:00
|
|
|
if(conn->datastream) {
|
2024-03-11 19:35:07 +08:00
|
|
|
result = conn->datastream(data, conn, &didwhat, select_bits);
|
|
|
|
if(result || data->req.done)
|
2022-11-11 18:45:34 +08:00
|
|
|
goto out;
|
2021-05-31 21:11:27 +08:00
|
|
|
}
|
|
|
|
else {
|
2020-12-14 21:10:33 +08:00
|
|
|
#endif
|
2008-08-09 04:37:54 +08:00
|
|
|
/* We go ahead and do a read if we have a readable socket or if
|
|
|
|
the stream was rewound (in which case we have data in a
|
|
|
|
buffer) */
|
2023-04-21 18:04:46 +08:00
|
|
|
if((k->keepon & KEEP_RECV) && (select_bits & CURL_CSELECT_IN)) {
|
2024-03-11 19:35:07 +08:00
|
|
|
result = readwrite_data(data, k, &didwhat);
|
|
|
|
if(result || data->req.done)
|
2022-11-11 18:45:34 +08:00
|
|
|
goto out;
|
2008-08-09 04:37:54 +08:00
|
|
|
}
|
2000-05-22 22:09:31 +08:00
|
|
|
|
2008-08-09 04:37:54 +08:00
|
|
|
/* If we still have writing to do, we check if we have a writable socket. */
|
2024-03-12 00:23:15 +08:00
|
|
|
if(((k->keepon & KEEP_SEND) && (select_bits & CURL_CSELECT_OUT)) ||
|
|
|
|
(k->keepon & KEEP_SEND_TIMED)) {
|
2008-08-09 04:37:54 +08:00
|
|
|
/* write */
|
2004-05-17 14:50:08 +08:00
|
|
|
|
2024-02-28 21:51:53 +08:00
|
|
|
result = readwrite_upload(data, &didwhat);
|
2008-08-09 04:37:54 +08:00
|
|
|
if(result)
|
2022-11-11 18:45:34 +08:00
|
|
|
goto out;
|
2008-08-09 04:37:54 +08:00
|
|
|
}
|
2021-05-31 21:11:27 +08:00
|
|
|
#ifdef USE_HYPER
|
|
|
|
}
|
|
|
|
#endif
|
2000-10-03 19:02:52 +08:00
|
|
|
|
2023-02-17 19:53:13 +08:00
|
|
|
now = Curl_now();
|
2020-12-26 22:43:25 +08:00
|
|
|
if(!didwhat) {
|
2022-12-30 16:14:55 +08:00
|
|
|
result = Curl_conn_ev_data_idle(data);
|
|
|
|
if(result)
|
|
|
|
goto out;
|
2002-01-03 23:01:22 +08:00
|
|
|
}
|
2001-11-01 20:18:53 +08:00
|
|
|
|
2021-01-18 18:56:50 +08:00
|
|
|
if(Curl_pgrsUpdate(data))
|
2002-01-03 23:01:22 +08:00
|
|
|
result = CURLE_ABORTED_BY_CALLBACK;
|
|
|
|
else
|
2023-02-17 19:53:13 +08:00
|
|
|
result = Curl_speedcheck(data, now);
|
2007-11-05 17:45:09 +08:00
|
|
|
if(result)
|
2022-11-11 18:45:34 +08:00
|
|
|
goto out;
|
2004-05-17 14:50:08 +08:00
|
|
|
|
2010-03-25 00:02:17 +08:00
|
|
|
if(k->keepon) {
|
2023-02-17 19:53:13 +08:00
|
|
|
if(0 > Curl_timeleft(data, &now, FALSE)) {
|
2010-03-25 00:02:17 +08:00
|
|
|
if(k->size != -1) {
|
2019-01-02 06:04:57 +08:00
|
|
|
failf(data, "Operation timed out after %" CURL_FORMAT_TIMEDIFF_T
|
|
|
|
" milliseconds with %" CURL_FORMAT_CURL_OFF_T " out of %"
|
2013-12-31 19:10:25 +08:00
|
|
|
CURL_FORMAT_CURL_OFF_T " bytes received",
|
2023-02-17 19:53:13 +08:00
|
|
|
Curl_timediff(now, data->progress.t_startsingle),
|
2017-10-23 18:05:49 +08:00
|
|
|
k->bytecount, k->size);
|
2010-05-28 03:03:46 +08:00
|
|
|
}
|
|
|
|
else {
|
2019-01-02 06:04:57 +08:00
|
|
|
failf(data, "Operation timed out after %" CURL_FORMAT_TIMEDIFF_T
|
|
|
|
" milliseconds with %" CURL_FORMAT_CURL_OFF_T " bytes received",
|
2023-02-17 19:53:13 +08:00
|
|
|
Curl_timediff(now, data->progress.t_startsingle),
|
2017-10-23 18:05:49 +08:00
|
|
|
k->bytecount);
|
2010-03-25 00:02:17 +08:00
|
|
|
}
|
2022-11-11 18:45:34 +08:00
|
|
|
result = CURLE_OPERATION_TIMEDOUT;
|
|
|
|
goto out;
|
2006-07-26 02:38:51 +08:00
|
|
|
}
|
2002-01-03 23:01:22 +08:00
|
|
|
}
|
2010-03-25 00:02:17 +08:00
|
|
|
else {
|
2002-01-03 23:01:22 +08:00
|
|
|
/*
|
|
|
|
* The transfer has been performed. Just make some general checks before
|
|
|
|
* returning.
|
|
|
|
*/
|
2022-11-11 17:57:04 +08:00
|
|
|
if(!(data->req.no_body) && (k->size != -1) &&
|
2006-09-08 05:49:20 +08:00
|
|
|
(k->bytecount != k->size) &&
|
2006-04-26 15:40:37 +08:00
|
|
|
#ifdef CURL_DO_LINEEND_CONV
|
2024-07-01 22:47:21 +08:00
|
|
|
/* Most FTP servers do not adjust their file SIZE response for CRLFs,
|
|
|
|
so we will check to see if the discrepancy can be explained
|
|
|
|
by the number of CRLFs we have changed to LFs.
|
2008-05-09 20:53:42 +08:00
|
|
|
*/
|
2006-09-08 05:49:20 +08:00
|
|
|
(k->bytecount != (k->size + data->state.crlf_conversions)) &&
|
2006-04-26 15:40:37 +08:00
|
|
|
#endif /* CURL_DO_LINEEND_CONV */
|
2017-04-25 16:49:53 +08:00
|
|
|
!k->newurl) {
|
2013-12-31 19:10:25 +08:00
|
|
|
failf(data, "transfer closed with %" CURL_FORMAT_CURL_OFF_T
|
2017-04-25 16:49:53 +08:00
|
|
|
" bytes remaining to read", k->size - k->bytecount);
|
2022-11-11 18:45:34 +08:00
|
|
|
result = CURLE_PARTIAL_FILE;
|
|
|
|
goto out;
|
2002-01-03 23:01:22 +08:00
|
|
|
}
|
2022-11-11 18:45:34 +08:00
|
|
|
if(Curl_pgrsUpdate(data)) {
|
|
|
|
result = CURLE_ABORTED_BY_CALLBACK;
|
|
|
|
goto out;
|
2000-05-22 22:09:31 +08:00
|
|
|
}
|
|
|
|
}
|
2001-05-13 00:11:14 +08:00
|
|
|
|
2024-03-11 19:35:07 +08:00
|
|
|
/* If there is nothing more to send/recv, the request is done */
|
|
|
|
if(0 == (k->keepon&(KEEP_RECVBITS|KEEP_SENDBITS)))
|
|
|
|
data->req.done = TRUE;
|
|
|
|
|
2022-11-11 18:45:34 +08:00
|
|
|
out:
|
2022-12-30 16:14:55 +08:00
|
|
|
if(result)
|
2023-05-23 18:48:58 +08:00
|
|
|
DEBUGF(infof(data, "Curl_readwrite() -> %d", result));
|
2022-11-11 18:45:34 +08:00
|
|
|
return result;
|
2002-01-03 23:01:22 +08:00
|
|
|
}
|
|
|
|
|
2015-10-06 02:39:10 +08:00
|
|
|
/* Curl_init_CONNECT() gets called each time the handle switches to CONNECT
|
|
|
|
which means this gets called once for each subsequent redirect etc */
|
2016-06-21 21:47:12 +08:00
|
|
|
void Curl_init_CONNECT(struct Curl_easy *data)
|
2015-10-06 02:39:10 +08:00
|
|
|
{
|
|
|
|
data->state.fread_func = data->set.fread_func_set;
|
|
|
|
data->state.in = data->set.in_set;
|
2023-04-25 14:28:01 +08:00
|
|
|
data->state.upload = (data->state.httpreq == HTTPREQ_PUT);
|
2015-10-06 02:39:10 +08:00
|
|
|
}
|
|
|
|
|
2004-04-26 15:12:52 +08:00
|
|
|
/*
|
2015-10-06 02:39:10 +08:00
|
|
|
* Curl_pretransfer() is called immediately before a transfer starts, and only
|
|
|
|
* once for one transfer no matter if it has redirects or do multi-pass
|
|
|
|
* authentication etc.
|
2004-04-26 15:12:52 +08:00
|
|
|
*/
|
2016-06-21 21:47:12 +08:00
|
|
|
CURLcode Curl_pretransfer(struct Curl_easy *data)
|
2002-01-03 23:01:22 +08:00
|
|
|
{
|
2014-10-24 04:56:35 +08:00
|
|
|
CURLcode result;
|
2018-11-02 02:16:15 +08:00
|
|
|
|
2021-03-26 21:25:45 +08:00
|
|
|
if(!data->state.url && !data->set.uh) {
|
2024-07-01 22:47:21 +08:00
|
|
|
/* we cannot do anything without URL */
|
2022-04-16 17:55:05 +08:00
|
|
|
failf(data, "No URL set");
|
2001-04-11 22:14:28 +08:00
|
|
|
return CURLE_URL_MALFORMAT;
|
2005-09-21 14:38:33 +08:00
|
|
|
}
|
2018-11-02 02:16:15 +08:00
|
|
|
|
2017-07-04 05:52:10 +08:00
|
|
|
/* since the URL may have been redirected in a previous use of this handle */
|
2021-03-26 21:25:45 +08:00
|
|
|
if(data->state.url_alloc) {
|
2017-07-04 05:52:10 +08:00
|
|
|
/* the already set URL is allocated, free it first! */
|
2021-03-26 21:25:45 +08:00
|
|
|
Curl_safefree(data->state.url);
|
|
|
|
data->state.url_alloc = FALSE;
|
2017-07-04 05:52:10 +08:00
|
|
|
}
|
2018-11-02 02:16:15 +08:00
|
|
|
|
2021-03-26 21:25:45 +08:00
|
|
|
if(!data->state.url && data->set.uh) {
|
2018-11-02 02:16:15 +08:00
|
|
|
CURLUcode uc;
|
2020-07-12 06:45:27 +08:00
|
|
|
free(data->set.str[STRING_SET_URL]);
|
2018-11-02 02:16:15 +08:00
|
|
|
uc = curl_url_get(data->set.uh,
|
2020-07-12 06:45:27 +08:00
|
|
|
CURLUPART_URL, &data->set.str[STRING_SET_URL], 0);
|
2018-11-02 02:16:15 +08:00
|
|
|
if(uc) {
|
2022-04-16 17:55:05 +08:00
|
|
|
failf(data, "No URL set");
|
2018-11-02 02:16:15 +08:00
|
|
|
return CURLE_URL_MALFORMAT;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-05-08 06:12:25 +08:00
|
|
|
if(data->set.postfields && data->set.set_resume_from) {
|
2024-07-01 22:47:21 +08:00
|
|
|
/* we cannot */
|
2023-05-08 06:12:25 +08:00
|
|
|
failf(data, "cannot mix POSTFIELDS with RESUME_FROM");
|
|
|
|
return CURLE_BAD_FUNCTION_ARGUMENT;
|
|
|
|
}
|
|
|
|
|
2021-02-08 22:56:10 +08:00
|
|
|
data->state.prefer_ascii = data->set.prefer_ascii;
|
2023-08-17 20:18:06 +08:00
|
|
|
#ifdef CURL_LIST_ONLY_PROTOCOL
|
2021-02-08 23:40:34 +08:00
|
|
|
data->state.list_only = data->set.list_only;
|
2023-08-17 20:18:06 +08:00
|
|
|
#endif
|
2020-06-02 04:58:46 +08:00
|
|
|
data->state.httpreq = data->set.method;
|
2021-03-26 21:25:45 +08:00
|
|
|
data->state.url = data->set.str[STRING_SET_URL];
|
2001-04-11 22:14:28 +08:00
|
|
|
|
2005-04-07 23:27:13 +08:00
|
|
|
/* Init the SSL session ID cache here. We do it here since we want to do it
|
2012-01-19 06:39:30 +08:00
|
|
|
after the *_setopt() calls (that could specify the size of the cache) but
|
2005-04-07 23:27:13 +08:00
|
|
|
before any transfer takes place. */
|
2016-11-17 01:49:15 +08:00
|
|
|
result = Curl_ssl_initsessions(data, data->set.general_ssl.max_ssl_sessions);
|
2014-10-24 04:56:35 +08:00
|
|
|
if(result)
|
|
|
|
return result;
|
2001-08-28 16:37:54 +08:00
|
|
|
|
2022-09-07 15:51:51 +08:00
|
|
|
data->state.requests = 0;
|
2021-02-09 06:00:21 +08:00
|
|
|
data->state.followlocation = 0; /* reset the location-follow counter */
|
2001-08-31 06:48:34 +08:00
|
|
|
data->state.this_is_a_follow = FALSE; /* reset this */
|
2001-11-03 06:30:34 +08:00
|
|
|
data->state.errorbuf = FALSE; /* no error has occurred */
|
2021-02-11 23:30:32 +08:00
|
|
|
data->state.httpwant = data->set.httpwant;
|
|
|
|
data->state.httpversion = 0;
|
2004-04-23 04:07:41 +08:00
|
|
|
data->state.authproblem = FALSE;
|
2004-05-04 15:52:53 +08:00
|
|
|
data->state.authhost.want = data->set.httpauth;
|
|
|
|
data->state.authproxy.want = data->set.proxyauth;
|
2008-10-09 06:01:23 +08:00
|
|
|
Curl_safefree(data->info.wouldredirect);
|
2022-12-30 16:14:55 +08:00
|
|
|
Curl_data_priority_clear_state(data);
|
2003-06-26 19:30:26 +08:00
|
|
|
|
2020-06-02 04:58:46 +08:00
|
|
|
if(data->state.httpreq == HTTPREQ_PUT)
|
2015-06-24 08:48:37 +08:00
|
|
|
data->state.infilesize = data->set.filesize;
|
2020-06-02 04:58:46 +08:00
|
|
|
else if((data->state.httpreq != HTTPREQ_GET) &&
|
|
|
|
(data->state.httpreq != HTTPREQ_HEAD)) {
|
2015-06-24 08:48:37 +08:00
|
|
|
data->state.infilesize = data->set.postfieldsize;
|
2017-05-30 06:45:54 +08:00
|
|
|
if(data->set.postfields && (data->state.infilesize == -1))
|
|
|
|
data->state.infilesize = (curl_off_t)strlen(data->set.postfields);
|
|
|
|
}
|
2019-02-11 16:17:07 +08:00
|
|
|
else
|
|
|
|
data->state.infilesize = 0;
|
2015-06-24 08:48:37 +08:00
|
|
|
|
2005-08-17 16:55:43 +08:00
|
|
|
/* If there is a list of cookie files to read, do it now! */
|
2022-12-22 20:09:16 +08:00
|
|
|
Curl_cookie_loadfiles(data);
|
|
|
|
|
2010-11-06 05:31:40 +08:00
|
|
|
/* If there is a list of host pairs to deal with */
|
2021-03-26 21:25:45 +08:00
|
|
|
if(data->state.resolve)
|
2014-10-24 04:56:35 +08:00
|
|
|
result = Curl_loadhostpairs(data);
|
2002-10-17 15:10:39 +08:00
|
|
|
|
2022-12-27 18:50:20 +08:00
|
|
|
/* If there is a list of hsts files to read */
|
|
|
|
Curl_hsts_loadfiles(data);
|
|
|
|
|
2014-10-24 04:56:35 +08:00
|
|
|
if(!result) {
|
2010-12-21 05:17:41 +08:00
|
|
|
/* Allow data->set.use_port to set which port to use. This needs to be
|
|
|
|
* disabled for example when we follow Location: headers to URLs using
|
|
|
|
* different ports! */
|
|
|
|
data->state.allow_port = TRUE;
|
2002-01-03 23:01:22 +08:00
|
|
|
|
2003-12-02 18:12:44 +08:00
|
|
|
#if defined(HAVE_SIGNAL) && defined(SIGPIPE) && !defined(HAVE_MSG_NOSIGNAL)
|
2010-12-21 05:17:41 +08:00
|
|
|
/*************************************************************
|
|
|
|
* Tell signal handler to ignore SIGPIPE
|
|
|
|
*************************************************************/
|
|
|
|
if(!data->set.no_signal)
|
|
|
|
data->state.prev_signal = signal(SIGPIPE, SIG_IGN);
|
2004-05-17 14:50:08 +08:00
|
|
|
#endif
|
2001-08-15 14:53:10 +08:00
|
|
|
|
2010-12-21 05:17:41 +08:00
|
|
|
Curl_initinfo(data); /* reset session-specific information "variables" */
|
2017-06-22 01:15:46 +08:00
|
|
|
Curl_pgrsResetTransferSizes(data);
|
2010-12-21 05:17:41 +08:00
|
|
|
Curl_pgrsStartNow(data);
|
2000-06-16 21:14:27 +08:00
|
|
|
|
2023-08-23 20:47:45 +08:00
|
|
|
/* In case the handle is reused and an authentication method was picked
|
2012-11-06 06:31:24 +08:00
|
|
|
in the session we need to make sure we only use the one(s) we now
|
|
|
|
consider to be fine */
|
|
|
|
data->state.authhost.picked &= data->state.authhost.want;
|
|
|
|
data->state.authproxy.picked &= data->state.authproxy.want;
|
2016-05-15 06:37:36 +08:00
|
|
|
|
2019-05-05 23:08:21 +08:00
|
|
|
#ifndef CURL_DISABLE_FTP
|
2022-06-01 20:30:55 +08:00
|
|
|
data->state.wildcardmatch = data->set.wildcard_enabled;
|
2017-10-26 05:51:50 +08:00
|
|
|
if(data->state.wildcardmatch) {
|
2023-02-28 06:57:23 +08:00
|
|
|
struct WildcardData *wc;
|
|
|
|
if(!data->wildcard) {
|
|
|
|
data->wildcard = calloc(1, sizeof(struct WildcardData));
|
|
|
|
if(!data->wildcard)
|
|
|
|
return CURLE_OUT_OF_MEMORY;
|
|
|
|
}
|
|
|
|
wc = data->wildcard;
|
2023-10-19 19:10:38 +08:00
|
|
|
if(wc->state < CURLWC_INIT) {
|
2023-03-26 23:43:28 +08:00
|
|
|
if(wc->ftpwc)
|
|
|
|
wc->dtor(wc->ftpwc);
|
|
|
|
Curl_safefree(wc->pattern);
|
|
|
|
Curl_safefree(wc->path);
|
2016-05-15 06:37:36 +08:00
|
|
|
result = Curl_wildcard_init(wc); /* init wildcard structures */
|
|
|
|
if(result)
|
2016-05-16 11:48:47 +08:00
|
|
|
return CURLE_OUT_OF_MEMORY;
|
2016-05-15 06:37:36 +08:00
|
|
|
}
|
|
|
|
}
|
2019-05-05 23:08:21 +08:00
|
|
|
#endif
|
2021-09-16 14:40:21 +08:00
|
|
|
result = Curl_hsts_loadcb(data, data->hsts);
|
2010-12-21 05:17:41 +08:00
|
|
|
}
|
2010-08-29 06:16:34 +08:00
|
|
|
|
2021-01-05 21:30:21 +08:00
|
|
|
/*
|
|
|
|
* Set user-agent. Used for HTTP, but since we can attempt to tunnel
|
2024-07-01 22:47:21 +08:00
|
|
|
* basically anything through an HTTP proxy we cannot limit this based on
|
2021-01-05 21:30:21 +08:00
|
|
|
* protocol.
|
|
|
|
*/
|
|
|
|
if(data->set.str[STRING_USERAGENT]) {
|
|
|
|
Curl_safefree(data->state.aptr.uagent);
|
|
|
|
data->state.aptr.uagent =
|
|
|
|
aprintf("User-Agent: %s\r\n", data->set.str[STRING_USERAGENT]);
|
|
|
|
if(!data->state.aptr.uagent)
|
|
|
|
return CURLE_OUT_OF_MEMORY;
|
|
|
|
}
|
|
|
|
|
2021-02-12 17:27:42 +08:00
|
|
|
if(!result)
|
|
|
|
result = Curl_setstropt(&data->state.aptr.user,
|
|
|
|
data->set.str[STRING_USERNAME]);
|
|
|
|
if(!result)
|
|
|
|
result = Curl_setstropt(&data->state.aptr.passwd,
|
|
|
|
data->set.str[STRING_PASSWORD]);
|
2024-03-26 07:19:23 +08:00
|
|
|
#ifndef CURL_DISABLE_PROXY
|
2021-02-12 17:27:42 +08:00
|
|
|
if(!result)
|
|
|
|
result = Curl_setstropt(&data->state.aptr.proxyuser,
|
|
|
|
data->set.str[STRING_PROXYUSERNAME]);
|
|
|
|
if(!result)
|
|
|
|
result = Curl_setstropt(&data->state.aptr.proxypasswd,
|
|
|
|
data->set.str[STRING_PROXYPASSWORD]);
|
2024-03-26 07:19:23 +08:00
|
|
|
#endif
|
2021-02-12 17:27:42 +08:00
|
|
|
|
2021-01-05 21:30:21 +08:00
|
|
|
data->req.headerbytecount = 0;
|
2022-03-17 17:20:19 +08:00
|
|
|
Curl_headers_cleanup(data);
|
2014-10-24 04:56:35 +08:00
|
|
|
return result;
|
2002-01-03 23:01:22 +08:00
|
|
|
}
|
|
|
|
|
2004-04-26 15:12:52 +08:00
|
|
|
/*
|
|
|
|
* Curl_posttransfer() is called immediately after a transfer ends
|
|
|
|
*/
|
2016-06-21 21:47:12 +08:00
|
|
|
CURLcode Curl_posttransfer(struct Curl_easy *data)
|
2002-01-03 23:01:22 +08:00
|
|
|
{
|
2003-12-02 18:12:44 +08:00
|
|
|
#if defined(HAVE_SIGNAL) && defined(SIGPIPE) && !defined(HAVE_MSG_NOSIGNAL)
|
2002-01-03 23:01:22 +08:00
|
|
|
/* restore the signal handler for SIGPIPE before we get back */
|
2002-08-09 06:52:50 +08:00
|
|
|
if(!data->set.no_signal)
|
|
|
|
signal(SIGPIPE, data->state.prev_signal);
|
2003-12-02 21:40:12 +08:00
|
|
|
#else
|
|
|
|
(void)data; /* unused parameter */
|
2004-05-17 14:50:08 +08:00
|
|
|
#endif
|
2002-01-03 23:01:22 +08:00
|
|
|
|
|
|
|
return CURLE_OK;
|
|
|
|
}
|
|
|
|
|
2004-04-26 15:12:52 +08:00
|
|
|
/*
|
|
|
|
* Curl_follow() handles the URL redirect magic. Pass in the 'newurl' string
|
|
|
|
* as given by the remote server and set up the new URL to request.
|
2018-10-02 15:58:04 +08:00
|
|
|
*
|
|
|
|
* This function DOES NOT FREE the given url.
|
2004-04-26 15:12:52 +08:00
|
|
|
*/
|
2016-06-21 21:47:12 +08:00
|
|
|
CURLcode Curl_follow(struct Curl_easy *data,
|
2017-05-23 16:32:18 +08:00
|
|
|
char *newurl, /* the Location: string */
|
2013-01-04 09:50:28 +08:00
|
|
|
followtype type) /* see transfer.h */
|
2002-10-07 21:38:34 +08:00
|
|
|
{
|
2008-10-10 06:14:38 +08:00
|
|
|
#ifdef CURL_DISABLE_HTTP
|
|
|
|
(void)data;
|
|
|
|
(void)newurl;
|
|
|
|
(void)type;
|
|
|
|
/* Location: following will not happen when HTTP is disabled */
|
|
|
|
return CURLE_TOO_MANY_REDIRECTS;
|
|
|
|
#else
|
|
|
|
|
2002-10-07 21:38:34 +08:00
|
|
|
/* Location: redirect */
|
2008-05-01 05:20:08 +08:00
|
|
|
bool disallowport = FALSE;
|
2017-05-23 16:32:18 +08:00
|
|
|
bool reachedmax = FALSE;
|
2018-09-15 05:33:28 +08:00
|
|
|
CURLUcode uc;
|
2004-05-17 14:50:08 +08:00
|
|
|
|
2021-01-02 06:41:21 +08:00
|
|
|
DEBUGASSERT(type != FOLLOW_NONE);
|
|
|
|
|
2022-03-17 17:20:19 +08:00
|
|
|
if(type != FOLLOW_FAKE)
|
|
|
|
data->state.requests++; /* count all real follows */
|
2008-05-01 05:20:08 +08:00
|
|
|
if(type == FOLLOW_REDIR) {
|
2007-11-05 17:45:09 +08:00
|
|
|
if((data->set.maxredirs != -1) &&
|
2021-02-09 06:00:21 +08:00
|
|
|
(data->state.followlocation >= data->set.maxredirs)) {
|
2017-05-23 16:32:18 +08:00
|
|
|
reachedmax = TRUE;
|
|
|
|
type = FOLLOW_FAKE; /* switch to fake to store the would-be-redirected
|
|
|
|
to URL */
|
2006-01-30 16:20:52 +08:00
|
|
|
}
|
2017-05-23 16:32:18 +08:00
|
|
|
else {
|
2022-11-11 15:47:12 +08:00
|
|
|
data->state.followlocation++; /* count redirect-followings, including
|
|
|
|
auth reloads */
|
2002-10-07 21:38:34 +08:00
|
|
|
|
2017-05-23 16:32:18 +08:00
|
|
|
if(data->set.http_auto_referer) {
|
2021-02-23 21:54:46 +08:00
|
|
|
CURLU *u;
|
2021-03-29 15:32:14 +08:00
|
|
|
char *referer = NULL;
|
2021-02-23 21:54:46 +08:00
|
|
|
|
2017-05-23 16:32:18 +08:00
|
|
|
/* We are asked to automatically set the previous URL as the referer
|
|
|
|
when we get the next URL. We pick the ->url field, which may or may
|
|
|
|
not be 100% correct */
|
2002-10-07 21:38:34 +08:00
|
|
|
|
2021-03-26 21:25:45 +08:00
|
|
|
if(data->state.referer_alloc) {
|
|
|
|
Curl_safefree(data->state.referer);
|
|
|
|
data->state.referer_alloc = FALSE;
|
2017-05-23 16:32:18 +08:00
|
|
|
}
|
2002-10-07 21:38:34 +08:00
|
|
|
|
2021-03-27 12:03:00 +08:00
|
|
|
/* Make a copy of the URL without credentials and fragment */
|
2021-02-23 21:54:46 +08:00
|
|
|
u = curl_url();
|
|
|
|
if(!u)
|
|
|
|
return CURLE_OUT_OF_MEMORY;
|
|
|
|
|
|
|
|
uc = curl_url_set(u, CURLUPART_URL, data->state.url, 0);
|
|
|
|
if(!uc)
|
|
|
|
uc = curl_url_set(u, CURLUPART_FRAGMENT, NULL, 0);
|
|
|
|
if(!uc)
|
|
|
|
uc = curl_url_set(u, CURLUPART_USER, NULL, 0);
|
|
|
|
if(!uc)
|
|
|
|
uc = curl_url_set(u, CURLUPART_PASSWORD, NULL, 0);
|
|
|
|
if(!uc)
|
|
|
|
uc = curl_url_get(u, CURLUPART_URL, &referer, 0);
|
|
|
|
|
|
|
|
curl_url_cleanup(u);
|
|
|
|
|
2021-03-29 15:32:14 +08:00
|
|
|
if(uc || !referer)
|
2017-05-23 16:32:18 +08:00
|
|
|
return CURLE_OUT_OF_MEMORY;
|
2021-02-23 21:54:46 +08:00
|
|
|
|
|
|
|
data->state.referer = referer;
|
2021-03-26 21:25:45 +08:00
|
|
|
data->state.referer_alloc = TRUE; /* yes, free this later */
|
2011-10-13 03:32:10 +08:00
|
|
|
}
|
2008-05-01 05:20:08 +08:00
|
|
|
}
|
2002-10-07 21:38:34 +08:00
|
|
|
}
|
|
|
|
|
2021-01-02 06:41:21 +08:00
|
|
|
if((type != FOLLOW_RETRY) &&
|
|
|
|
(data->req.httpcode != 401) && (data->req.httpcode != 407) &&
|
2023-07-09 05:57:29 +08:00
|
|
|
Curl_is_absolute_url(newurl, NULL, 0, FALSE)) {
|
2021-01-02 06:41:21 +08:00
|
|
|
/* If this is not redirect due to a 401 or 407 response and an absolute
|
2024-07-01 22:47:21 +08:00
|
|
|
URL: do not allow a custom port number */
|
2008-05-01 05:20:08 +08:00
|
|
|
disallowport = TRUE;
|
2023-07-09 05:57:29 +08:00
|
|
|
}
|
2002-10-07 21:38:34 +08:00
|
|
|
|
2018-09-15 05:33:28 +08:00
|
|
|
DEBUGASSERT(data->state.uh);
|
2024-06-03 04:30:52 +08:00
|
|
|
uc = curl_url_set(data->state.uh, CURLUPART_URL, newurl, (unsigned int)
|
|
|
|
((type == FOLLOW_FAKE) ? CURLU_NON_SUPPORT_SCHEME :
|
|
|
|
((type == FOLLOW_REDIR) ? CURLU_URLENCODE : 0) |
|
|
|
|
CURLU_ALLOW_SPACE |
|
|
|
|
(data->set.path_as_is ? CURLU_PATH_AS_IS : 0)));
|
2018-12-11 23:08:51 +08:00
|
|
|
if(uc) {
|
2022-09-14 15:18:30 +08:00
|
|
|
if(type != FOLLOW_FAKE) {
|
|
|
|
failf(data, "The redirect target URL could not be parsed: %s",
|
|
|
|
curl_url_strerror(uc));
|
2018-12-11 23:08:51 +08:00
|
|
|
return Curl_uc_to_curlcode(uc);
|
2022-09-14 15:18:30 +08:00
|
|
|
}
|
2018-12-11 23:08:51 +08:00
|
|
|
|
|
|
|
/* the URL could not be parsed for some reason, but since this is FAKE
|
|
|
|
mode, just duplicate the field as-is */
|
|
|
|
newurl = strdup(newurl);
|
|
|
|
if(!newurl)
|
|
|
|
return CURLE_OUT_OF_MEMORY;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
uc = curl_url_get(data->state.uh, CURLUPART_URL, &newurl, 0);
|
|
|
|
if(uc)
|
|
|
|
return Curl_uc_to_curlcode(uc);
|
2022-04-25 22:24:33 +08:00
|
|
|
|
|
|
|
/* Clear auth if this redirects to a different port number or protocol,
|
|
|
|
unless permitted */
|
|
|
|
if(!data->set.allow_auth_to_other_hosts && (type != FOLLOW_FAKE)) {
|
|
|
|
char *portnum;
|
|
|
|
int port;
|
|
|
|
bool clear = FALSE;
|
|
|
|
|
|
|
|
if(data->set.use_port && data->state.allow_port)
|
|
|
|
/* a custom port is used */
|
|
|
|
port = (int)data->set.use_port;
|
|
|
|
else {
|
|
|
|
uc = curl_url_get(data->state.uh, CURLUPART_PORT, &portnum,
|
|
|
|
CURLU_DEFAULT_PORT);
|
|
|
|
if(uc) {
|
|
|
|
free(newurl);
|
|
|
|
return Curl_uc_to_curlcode(uc);
|
|
|
|
}
|
|
|
|
port = atoi(portnum);
|
|
|
|
free(portnum);
|
|
|
|
}
|
|
|
|
if(port != data->info.conn_remote_port) {
|
|
|
|
infof(data, "Clear auth, redirects to port from %u to %u",
|
|
|
|
data->info.conn_remote_port, port);
|
|
|
|
clear = TRUE;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
char *scheme;
|
|
|
|
const struct Curl_handler *p;
|
|
|
|
uc = curl_url_get(data->state.uh, CURLUPART_SCHEME, &scheme, 0);
|
|
|
|
if(uc) {
|
|
|
|
free(newurl);
|
|
|
|
return Curl_uc_to_curlcode(uc);
|
|
|
|
}
|
|
|
|
|
2023-10-27 17:53:26 +08:00
|
|
|
p = Curl_get_scheme_handler(scheme);
|
2022-04-25 22:24:33 +08:00
|
|
|
if(p && (p->protocol != data->info.conn_protocol)) {
|
|
|
|
infof(data, "Clear auth, redirects scheme from %s to %s",
|
|
|
|
data->info.conn_scheme, scheme);
|
|
|
|
clear = TRUE;
|
|
|
|
}
|
|
|
|
free(scheme);
|
|
|
|
}
|
|
|
|
if(clear) {
|
|
|
|
Curl_safefree(data->state.aptr.user);
|
|
|
|
Curl_safefree(data->state.aptr.passwd);
|
|
|
|
}
|
|
|
|
}
|
2018-12-11 23:08:51 +08:00
|
|
|
}
|
2003-06-26 19:30:26 +08:00
|
|
|
|
2008-05-01 05:20:08 +08:00
|
|
|
if(type == FOLLOW_FAKE) {
|
2024-07-01 22:47:21 +08:00
|
|
|
/* we are only figuring out the new URL if we would have followed locations
|
|
|
|
but now we are done so we can get out! */
|
2008-05-01 05:20:08 +08:00
|
|
|
data->info.wouldredirect = newurl;
|
2017-05-23 16:32:18 +08:00
|
|
|
|
|
|
|
if(reachedmax) {
|
|
|
|
failf(data, "Maximum (%ld) redirects followed", data->set.maxredirs);
|
|
|
|
return CURLE_TOO_MANY_REDIRECTS;
|
|
|
|
}
|
2008-05-01 05:20:08 +08:00
|
|
|
return CURLE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
if(disallowport)
|
|
|
|
data->state.allow_port = FALSE;
|
|
|
|
|
2021-03-26 21:25:45 +08:00
|
|
|
if(data->state.url_alloc)
|
|
|
|
Curl_safefree(data->state.url);
|
2004-05-17 14:50:08 +08:00
|
|
|
|
2021-03-26 21:25:45 +08:00
|
|
|
data->state.url = newurl;
|
|
|
|
data->state.url_alloc = TRUE;
|
2024-03-11 19:35:07 +08:00
|
|
|
Curl_req_soft_reset(&data->req, data);
|
2021-07-06 23:05:17 +08:00
|
|
|
infof(data, "Issue another request to this URL: '%s'", data->state.url);
|
2002-10-07 21:38:34 +08:00
|
|
|
|
|
|
|
/*
|
2003-06-13 01:40:56 +08:00
|
|
|
* We get here when the HTTP code is 300-399 (and 401). We need to perform
|
2002-10-07 21:38:34 +08:00
|
|
|
* differently based on exactly what return code there was.
|
2003-05-23 00:09:54 +08:00
|
|
|
*
|
2004-05-05 14:57:26 +08:00
|
|
|
* News from 7.10.6: we can also get here on a 401 or 407, in case we act on
|
2022-10-26 14:59:35 +08:00
|
|
|
* an HTTP (proxy-) authentication scheme other than Basic.
|
2002-10-07 21:38:34 +08:00
|
|
|
*/
|
|
|
|
switch(data->info.httpcode) {
|
2008-01-10 17:16:21 +08:00
|
|
|
/* 401 - Act on a WWW-Authenticate, we keep on moving and do the
|
2004-05-05 14:57:26 +08:00
|
|
|
Authorization: XXXX header in the HTTP request code snippet */
|
2008-01-10 17:16:21 +08:00
|
|
|
/* 407 - Act on a Proxy-Authenticate, we keep on moving and do the
|
2004-05-05 14:57:26 +08:00
|
|
|
Proxy-Authorization: XXXX header in the HTTP request code snippet */
|
|
|
|
/* 300 - Multiple Choices */
|
|
|
|
/* 306 - Not used */
|
|
|
|
/* 307 - Temporary Redirect */
|
|
|
|
default: /* for all above (and the unknown ones) */
|
2024-07-01 22:47:21 +08:00
|
|
|
/* Some codes are explicitly mentioned since I have checked RFC2616 and
|
|
|
|
* they seem to be OK to POST to.
|
2002-10-07 21:38:34 +08:00
|
|
|
*/
|
|
|
|
break;
|
|
|
|
case 301: /* Moved Permanently */
|
2014-06-09 00:59:48 +08:00
|
|
|
/* (quote from RFC7231, section 6.4.2)
|
2004-05-17 14:50:08 +08:00
|
|
|
*
|
2014-06-09 00:59:48 +08:00
|
|
|
* Note: For historical reasons, a user agent MAY change the request
|
2024-07-01 22:47:21 +08:00
|
|
|
* method from POST to GET for the subsequent request. If this
|
2014-06-09 00:59:48 +08:00
|
|
|
* behavior is undesired, the 307 (Temporary Redirect) status code
|
|
|
|
* can be used instead.
|
2002-10-07 21:38:34 +08:00
|
|
|
*
|
|
|
|
* ----
|
2004-05-05 14:57:26 +08:00
|
|
|
*
|
2014-06-09 00:59:48 +08:00
|
|
|
* Many webservers expect this, so these servers often answers to a POST
|
|
|
|
* request with an error page. To be sure that libcurl gets the page that
|
2011-09-11 21:42:11 +08:00
|
|
|
* most user agents would get, libcurl has to force GET.
|
2007-09-26 20:44:59 +08:00
|
|
|
*
|
2020-12-31 17:11:49 +08:00
|
|
|
* This behavior is forbidden by RFC1945 and the obsolete RFC2616, and
|
2014-06-09 00:59:48 +08:00
|
|
|
* can be overridden with CURLOPT_POSTREDIR.
|
2002-10-07 21:38:34 +08:00
|
|
|
*/
|
2020-06-02 04:58:46 +08:00
|
|
|
if((data->state.httpreq == HTTPREQ_POST
|
|
|
|
|| data->state.httpreq == HTTPREQ_POST_FORM
|
|
|
|
|| data->state.httpreq == HTTPREQ_POST_MIME)
|
2012-03-30 15:40:04 +08:00
|
|
|
&& !(data->set.keep_post & CURL_REDIR_POST_301)) {
|
2021-07-06 23:05:17 +08:00
|
|
|
infof(data, "Switch from POST to GET");
|
2020-06-02 04:58:46 +08:00
|
|
|
data->state.httpreq = HTTPREQ_GET;
|
2024-02-29 17:12:39 +08:00
|
|
|
Curl_creader_set_rewind(data, FALSE);
|
2002-10-07 21:38:34 +08:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 302: /* Found */
|
2014-06-09 00:59:48 +08:00
|
|
|
/* (quote from RFC7231, section 6.4.3)
|
|
|
|
*
|
|
|
|
* Note: For historical reasons, a user agent MAY change the request
|
2024-07-01 22:47:21 +08:00
|
|
|
* method from POST to GET for the subsequent request. If this
|
2014-06-09 00:59:48 +08:00
|
|
|
* behavior is undesired, the 307 (Temporary Redirect) status code
|
|
|
|
* can be used instead.
|
|
|
|
*
|
|
|
|
* ----
|
|
|
|
*
|
|
|
|
* Many webservers expect this, so these servers often answers to a POST
|
|
|
|
* request with an error page. To be sure that libcurl gets the page that
|
|
|
|
* most user agents would get, libcurl has to force GET.
|
|
|
|
*
|
2020-12-31 17:11:49 +08:00
|
|
|
* This behavior is forbidden by RFC1945 and the obsolete RFC2616, and
|
2014-06-09 00:59:48 +08:00
|
|
|
* can be overridden with CURLOPT_POSTREDIR.
|
|
|
|
*/
|
2020-06-02 04:58:46 +08:00
|
|
|
if((data->state.httpreq == HTTPREQ_POST
|
|
|
|
|| data->state.httpreq == HTTPREQ_POST_FORM
|
|
|
|
|| data->state.httpreq == HTTPREQ_POST_MIME)
|
2012-03-30 15:40:04 +08:00
|
|
|
&& !(data->set.keep_post & CURL_REDIR_POST_302)) {
|
2021-07-06 23:05:17 +08:00
|
|
|
infof(data, "Switch from POST to GET");
|
2020-06-02 04:58:46 +08:00
|
|
|
data->state.httpreq = HTTPREQ_GET;
|
2024-02-29 17:12:39 +08:00
|
|
|
Curl_creader_set_rewind(data, FALSE);
|
2008-09-06 00:13:20 +08:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2002-10-07 21:38:34 +08:00
|
|
|
case 303: /* See Other */
|
2020-04-17 02:15:34 +08:00
|
|
|
/* 'See Other' location is not the resource but a substitute for the
|
|
|
|
* resource. In this case we switch the method to GET/HEAD, unless the
|
|
|
|
* method is POST and the user specified to keep it as POST.
|
|
|
|
* https://github.com/curl/curl/issues/5237#issuecomment-614641049
|
|
|
|
*/
|
2020-06-02 04:58:46 +08:00
|
|
|
if(data->state.httpreq != HTTPREQ_GET &&
|
|
|
|
((data->state.httpreq != HTTPREQ_POST &&
|
|
|
|
data->state.httpreq != HTTPREQ_POST_FORM &&
|
|
|
|
data->state.httpreq != HTTPREQ_POST_MIME) ||
|
2020-04-17 02:15:34 +08:00
|
|
|
!(data->set.keep_post & CURL_REDIR_POST_303))) {
|
2020-06-02 04:58:46 +08:00
|
|
|
data->state.httpreq = HTTPREQ_GET;
|
2021-07-06 23:05:17 +08:00
|
|
|
infof(data, "Switch to %s",
|
2022-11-11 17:57:04 +08:00
|
|
|
data->req.no_body?"HEAD":"GET");
|
2002-10-07 21:38:34 +08:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 304: /* Not Modified */
|
|
|
|
/* 304 means we did a conditional request and it was "Not modified".
|
2024-07-01 22:47:21 +08:00
|
|
|
* We should not get any Location: header in this response!
|
2002-10-07 21:38:34 +08:00
|
|
|
*/
|
|
|
|
break;
|
|
|
|
case 305: /* Use Proxy */
|
|
|
|
/* (quote from RFC2616, section 10.3.6):
|
|
|
|
* "The requested resource MUST be accessed through the proxy given
|
|
|
|
* by the Location field. The Location field gives the URI of the
|
2024-07-01 22:47:21 +08:00
|
|
|
* proxy. The recipient is expected to repeat this single request
|
2002-10-07 21:38:34 +08:00
|
|
|
* via the proxy. 305 responses MUST only be generated by origin
|
|
|
|
* servers."
|
|
|
|
*/
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
Curl_pgrsTime(data, TIMER_REDIRECT);
|
2017-06-22 01:15:46 +08:00
|
|
|
Curl_pgrsResetTransferSizes(data);
|
2002-10-07 21:38:34 +08:00
|
|
|
|
|
|
|
return CURLE_OK;
|
2008-10-10 06:14:38 +08:00
|
|
|
#endif /* CURL_DISABLE_HTTP */
|
2002-10-07 21:38:34 +08:00
|
|
|
}
|
|
|
|
|
2009-08-21 20:01:36 +08:00
|
|
|
/* Returns CURLE_OK *and* sets '*url' if a request retry is wanted.
|
2008-05-01 05:20:08 +08:00
|
|
|
|
|
|
|
NOTE: that the *url is malloc()ed. */
|
2021-01-19 17:24:35 +08:00
|
|
|
CURLcode Curl_retry_request(struct Curl_easy *data, char **url)
|
2005-01-30 06:31:06 +08:00
|
|
|
{
|
2021-01-19 17:24:35 +08:00
|
|
|
struct connectdata *conn = data->conn;
|
2018-04-20 02:03:30 +08:00
|
|
|
bool retry = FALSE;
|
2009-08-21 20:01:36 +08:00
|
|
|
*url = NULL;
|
|
|
|
|
2024-07-01 22:47:21 +08:00
|
|
|
/* if we are talking upload, we cannot do the checks below, unless the
|
|
|
|
protocol is HTTP as when uploading over HTTP we will still get a
|
|
|
|
response */
|
2023-04-25 14:28:01 +08:00
|
|
|
if(data->state.upload &&
|
2014-04-21 01:37:54 +08:00
|
|
|
!(conn->handler->protocol&(PROTO_FAMILY_HTTP|CURLPROTO_RTSP)))
|
2009-08-21 20:01:36 +08:00
|
|
|
return CURLE_OK;
|
2007-09-12 06:21:12 +08:00
|
|
|
|
2014-10-29 21:24:54 +08:00
|
|
|
if((data->req.bytecount + data->req.headerbytecount == 0) &&
|
2022-06-01 20:30:55 +08:00
|
|
|
conn->bits.reuse &&
|
2022-11-11 17:57:04 +08:00
|
|
|
(!data->req.no_body || (conn->handler->protocol & PROTO_FAMILY_HTTP))
|
2022-06-01 20:30:55 +08:00
|
|
|
#ifndef CURL_DISABLE_RTSP
|
|
|
|
&& (data->set.rtspreq != RTSPREQ_RECEIVE)
|
|
|
|
#endif
|
|
|
|
)
|
2023-08-23 20:47:45 +08:00
|
|
|
/* We got no data, we attempted to reuse a connection. For HTTP this
|
2017-02-03 22:58:41 +08:00
|
|
|
can be a retry so we try again regardless if we expected a body.
|
|
|
|
For other protocols we only try again only if we expected a body.
|
|
|
|
|
|
|
|
This might happen if the connection was left alive when we were
|
|
|
|
done using it before, but that was closed when we wanted to read from
|
|
|
|
it again. Bad luck. Retry the same request on a fresh connect! */
|
2018-04-20 02:03:30 +08:00
|
|
|
retry = TRUE;
|
|
|
|
else if(data->state.refused_stream &&
|
|
|
|
(data->req.bytecount + data->req.headerbytecount == 0) ) {
|
|
|
|
/* This was sent on a refused stream, safe to rerun. A refused stream
|
|
|
|
error can typically only happen on HTTP/2 level if the stream is safe
|
|
|
|
to issue again, but the nghttp2 API can deliver the message to other
|
|
|
|
streams as well, which is why this adds the check the data counters
|
|
|
|
too. */
|
2021-07-06 23:05:17 +08:00
|
|
|
infof(data, "REFUSED_STREAM, retrying a fresh connect");
|
2018-04-20 02:03:30 +08:00
|
|
|
data->state.refused_stream = FALSE; /* clear again */
|
|
|
|
retry = TRUE;
|
|
|
|
}
|
|
|
|
if(retry) {
|
2020-03-11 05:31:47 +08:00
|
|
|
#define CONN_MAX_RETRIES 5
|
2020-08-10 20:16:37 +08:00
|
|
|
if(data->state.retrycount++ >= CONN_MAX_RETRIES) {
|
2020-03-11 05:31:47 +08:00
|
|
|
failf(data, "Connection died, tried %d times before giving up",
|
|
|
|
CONN_MAX_RETRIES);
|
2020-08-10 20:16:37 +08:00
|
|
|
data->state.retrycount = 0;
|
2020-03-11 05:31:47 +08:00
|
|
|
return CURLE_SEND_ERROR;
|
|
|
|
}
|
2021-07-06 23:05:17 +08:00
|
|
|
infof(data, "Connection died, retrying a fresh connect (retry count: %d)",
|
|
|
|
data->state.retrycount);
|
2021-03-26 21:25:45 +08:00
|
|
|
*url = strdup(data->state.url);
|
2009-08-21 20:01:36 +08:00
|
|
|
if(!*url)
|
|
|
|
return CURLE_OUT_OF_MEMORY;
|
2005-01-30 06:31:06 +08:00
|
|
|
|
2014-05-20 16:32:23 +08:00
|
|
|
connclose(conn, "retry"); /* close this connection */
|
2024-07-01 22:47:21 +08:00
|
|
|
conn->bits.retry = TRUE; /* mark this as a connection we are about
|
2005-01-30 06:31:06 +08:00
|
|
|
to retry. Marking it this way should
|
|
|
|
prevent i.e HTTP transfers to return
|
|
|
|
error just because nothing has been
|
2011-04-19 21:54:13 +08:00
|
|
|
transferred! */
|
2024-02-29 17:12:39 +08:00
|
|
|
Curl_creader_set_rewind(data, TRUE);
|
2005-01-30 06:31:06 +08:00
|
|
|
}
|
2009-08-21 20:01:36 +08:00
|
|
|
return CURLE_OK;
|
2005-01-30 06:31:06 +08:00
|
|
|
}
|
2004-06-03 19:41:05 +08:00
|
|
|
|
2004-04-26 15:12:52 +08:00
|
|
|
/*
|
2024-06-10 19:32:13 +08:00
|
|
|
* xfer_setup() is called to setup basic properties for the transfer.
|
2004-04-26 15:12:52 +08:00
|
|
|
*/
|
2024-06-10 19:32:13 +08:00
|
|
|
static void xfer_setup(
|
2019-02-28 18:36:26 +08:00
|
|
|
struct Curl_easy *data, /* transfer */
|
2007-11-16 05:45:45 +08:00
|
|
|
int sockindex, /* socket index to read from or -1 */
|
|
|
|
curl_off_t size, /* -1 if unknown at this point */
|
|
|
|
bool getheader, /* TRUE if header parsing is wanted */
|
2024-06-10 19:32:13 +08:00
|
|
|
int writesockindex, /* socket index to write to, it may very well be
|
2007-11-16 05:45:45 +08:00
|
|
|
the same we read from. -1 disables */
|
2024-06-10 19:32:13 +08:00
|
|
|
bool shutdown /* shutdown connection at transfer end. Only
|
|
|
|
* supported when sending OR receiving. */
|
2007-11-16 05:45:45 +08:00
|
|
|
)
|
2001-01-17 21:19:01 +08:00
|
|
|
{
|
2019-02-28 18:36:26 +08:00
|
|
|
struct SingleRequest *k = &data->req;
|
|
|
|
struct connectdata *conn = data->conn;
|
lib: Curl_read/Curl_write clarifications
- replace `Curl_read()`, `Curl_write()` and `Curl_nwrite()` to
clarify when and at what level they operate
- send/recv of transfer related data is now done via
`Curl_xfer_send()/Curl_xfer_recv()` which no longer has
socket/socketindex as parameter. It decides on the transfer
setup of `conn->sockfd` and `conn->writesockfd` on which
connection filter chain to operate.
- send/recv on a specific connection filter chain is done via
`Curl_conn_send()/Curl_conn_recv()` which get the socket index
as parameter.
- rename `Curl_setup_transfer()` to `Curl_xfer_setup()` for
naming consistency
- clarify that the special CURLE_AGAIN hangling to return
`CURLE_OK` with length 0 only applies to `Curl_xfer_send()`
and CURLE_AGAIN is returned by all other send() variants.
- fix a bug in websocket `curl_ws_recv()` that mixed up data
when it arrived in more than a single chunk
The method for sending not just raw bytes, but bytes that are either
"headers" or "body". The send abstraction stack, to to bottom, now is:
* `Curl_req_send()`: has parameter to indicate amount of header bytes,
buffers all data.
* `Curl_xfer_send()`: knows on which socket index to send, returns
amount of bytes sent.
* `Curl_conn_send()`: called with socket index, returns amount of bytes
sent.
In addition there is `Curl_req_flush()` for writing out all buffered
bytes.
`Curl_req_send()` is active for requests without body,
`Curl_buffer_send()` still being used for others. This is because the
special quirks need to be addressed in future parts:
* `expect-100` handling
* `Curl_fillreadbuffer()` needs to add directly to the new
`data->req.sendbuf`
* special body handlings, like `chunked` encodings and line end
conversions will be moved into something like a Client Reader.
In functions of the pattern `CURLcode xxx_send(..., ssize_t *written)`,
replace the `ssize_t` with a `size_t`. It makes no sense to allow for negative
values as the returned `CURLcode` already specifies error conditions. This
allows easier handling of lengths without casting.
Closes #12964
2024-02-15 23:22:53 +08:00
|
|
|
bool want_send = Curl_req_want_send(data);
|
2022-05-17 03:18:46 +08:00
|
|
|
|
2007-11-16 05:45:45 +08:00
|
|
|
DEBUGASSERT(conn != NULL);
|
2007-02-22 03:03:20 +08:00
|
|
|
DEBUGASSERT((sockindex <= 1) && (sockindex >= -1));
|
2024-02-14 19:09:32 +08:00
|
|
|
DEBUGASSERT((writesockindex <= 1) && (writesockindex >= -1));
|
2024-06-10 19:32:13 +08:00
|
|
|
DEBUGASSERT(!shutdown || (sockindex == -1) || (writesockindex == -1));
|
2003-12-10 23:27:27 +08:00
|
|
|
|
lib: Curl_read/Curl_write clarifications
- replace `Curl_read()`, `Curl_write()` and `Curl_nwrite()` to
clarify when and at what level they operate
- send/recv of transfer related data is now done via
`Curl_xfer_send()/Curl_xfer_recv()` which no longer has
socket/socketindex as parameter. It decides on the transfer
setup of `conn->sockfd` and `conn->writesockfd` on which
connection filter chain to operate.
- send/recv on a specific connection filter chain is done via
`Curl_conn_send()/Curl_conn_recv()` which get the socket index
as parameter.
- rename `Curl_setup_transfer()` to `Curl_xfer_setup()` for
naming consistency
- clarify that the special CURLE_AGAIN hangling to return
`CURLE_OK` with length 0 only applies to `Curl_xfer_send()`
and CURLE_AGAIN is returned by all other send() variants.
- fix a bug in websocket `curl_ws_recv()` that mixed up data
when it arrived in more than a single chunk
The method for sending not just raw bytes, but bytes that are either
"headers" or "body". The send abstraction stack, to to bottom, now is:
* `Curl_req_send()`: has parameter to indicate amount of header bytes,
buffers all data.
* `Curl_xfer_send()`: knows on which socket index to send, returns
amount of bytes sent.
* `Curl_conn_send()`: called with socket index, returns amount of bytes
sent.
In addition there is `Curl_req_flush()` for writing out all buffered
bytes.
`Curl_req_send()` is active for requests without body,
`Curl_buffer_send()` still being used for others. This is because the
special quirks need to be addressed in future parts:
* `expect-100` handling
* `Curl_fillreadbuffer()` needs to add directly to the new
`data->req.sendbuf`
* special body handlings, like `chunked` encodings and line end
conversions will be moved into something like a Client Reader.
In functions of the pattern `CURLcode xxx_send(..., ssize_t *written)`,
replace the `ssize_t` with a `size_t`. It makes no sense to allow for negative
values as the returned `CURLcode` already specifies error conditions. This
allows easier handling of lengths without casting.
Closes #12964
2024-02-15 23:22:53 +08:00
|
|
|
if(conn->bits.multiplex || conn->httpversion >= 20 || want_send) {
|
2018-05-04 22:41:03 +08:00
|
|
|
/* when multiplexing, the read/write sockets need to be the same! */
|
|
|
|
conn->sockfd = sockindex == -1 ?
|
2018-05-12 05:54:26 +08:00
|
|
|
((writesockindex == -1 ? CURL_SOCKET_BAD : conn->sock[writesockindex])) :
|
|
|
|
conn->sock[sockindex];
|
2018-05-04 22:41:03 +08:00
|
|
|
conn->writesockfd = conn->sockfd;
|
lib: Curl_read/Curl_write clarifications
- replace `Curl_read()`, `Curl_write()` and `Curl_nwrite()` to
clarify when and at what level they operate
- send/recv of transfer related data is now done via
`Curl_xfer_send()/Curl_xfer_recv()` which no longer has
socket/socketindex as parameter. It decides on the transfer
setup of `conn->sockfd` and `conn->writesockfd` on which
connection filter chain to operate.
- send/recv on a specific connection filter chain is done via
`Curl_conn_send()/Curl_conn_recv()` which get the socket index
as parameter.
- rename `Curl_setup_transfer()` to `Curl_xfer_setup()` for
naming consistency
- clarify that the special CURLE_AGAIN hangling to return
`CURLE_OK` with length 0 only applies to `Curl_xfer_send()`
and CURLE_AGAIN is returned by all other send() variants.
- fix a bug in websocket `curl_ws_recv()` that mixed up data
when it arrived in more than a single chunk
The method for sending not just raw bytes, but bytes that are either
"headers" or "body". The send abstraction stack, to to bottom, now is:
* `Curl_req_send()`: has parameter to indicate amount of header bytes,
buffers all data.
* `Curl_xfer_send()`: knows on which socket index to send, returns
amount of bytes sent.
* `Curl_conn_send()`: called with socket index, returns amount of bytes
sent.
In addition there is `Curl_req_flush()` for writing out all buffered
bytes.
`Curl_req_send()` is active for requests without body,
`Curl_buffer_send()` still being used for others. This is because the
special quirks need to be addressed in future parts:
* `expect-100` handling
* `Curl_fillreadbuffer()` needs to add directly to the new
`data->req.sendbuf`
* special body handlings, like `chunked` encodings and line end
conversions will be moved into something like a Client Reader.
In functions of the pattern `CURLcode xxx_send(..., ssize_t *written)`,
replace the `ssize_t` with a `size_t`. It makes no sense to allow for negative
values as the returned `CURLcode` already specifies error conditions. This
allows easier handling of lengths without casting.
Closes #12964
2024-02-15 23:22:53 +08:00
|
|
|
if(want_send)
|
2020-04-08 00:16:01 +08:00
|
|
|
/* special and very HTTP-specific */
|
|
|
|
writesockindex = FIRSTSOCKET;
|
2018-05-04 22:41:03 +08:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
conn->sockfd = sockindex == -1 ?
|
2006-09-08 05:49:20 +08:00
|
|
|
CURL_SOCKET_BAD : conn->sock[sockindex];
|
2018-05-04 22:41:03 +08:00
|
|
|
conn->writesockfd = writesockindex == -1 ?
|
2006-09-08 05:49:20 +08:00
|
|
|
CURL_SOCKET_BAD:conn->sock[writesockindex];
|
2018-05-04 22:41:03 +08:00
|
|
|
}
|
2001-01-17 21:19:01 +08:00
|
|
|
|
2024-06-10 19:32:13 +08:00
|
|
|
k->getheader = getheader;
|
2007-11-25 07:16:55 +08:00
|
|
|
k->size = size;
|
2024-06-10 19:32:13 +08:00
|
|
|
k->shutdown = shutdown;
|
2001-01-17 21:19:01 +08:00
|
|
|
|
2007-11-16 05:45:45 +08:00
|
|
|
/* The code sequence below is placed in this function just because all
|
|
|
|
necessary input is not always known in do_complete() as this function may
|
|
|
|
be called after that */
|
|
|
|
|
2008-01-31 20:04:33 +08:00
|
|
|
if(!k->getheader) {
|
2007-11-16 05:45:45 +08:00
|
|
|
k->header = FALSE;
|
2007-11-25 07:16:55 +08:00
|
|
|
if(size > 0)
|
|
|
|
Curl_pgrsSetDownloadSize(data, size);
|
2007-11-16 05:45:45 +08:00
|
|
|
}
|
2024-07-01 22:47:21 +08:00
|
|
|
/* we want header and/or body, if neither then do not do this! */
|
2022-11-11 17:57:04 +08:00
|
|
|
if(k->getheader || !data->req.no_body) {
|
2007-11-16 05:45:45 +08:00
|
|
|
|
2018-05-04 22:41:03 +08:00
|
|
|
if(sockindex != -1)
|
2009-05-11 15:53:38 +08:00
|
|
|
k->keepon |= KEEP_RECV;
|
2007-11-16 05:45:45 +08:00
|
|
|
|
2024-03-12 00:23:15 +08:00
|
|
|
if(writesockindex != -1)
|
|
|
|
k->keepon |= KEEP_SEND;
|
2022-11-11 17:57:04 +08:00
|
|
|
} /* if(k->getheader || !data->req.no_body) */
|
2007-11-16 05:45:45 +08:00
|
|
|
|
2001-01-17 21:19:01 +08:00
|
|
|
}
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
|
2024-06-10 19:32:13 +08:00
|
|
|
void Curl_xfer_setup_nop(struct Curl_easy *data)
|
|
|
|
{
|
|
|
|
xfer_setup(data, -1, -1, FALSE, -1, FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Curl_xfer_setup1(struct Curl_easy *data,
|
|
|
|
int send_recv,
|
|
|
|
curl_off_t recv_size,
|
|
|
|
bool getheader)
|
|
|
|
{
|
|
|
|
int recv_index = (send_recv & CURL_XFER_RECV)? FIRSTSOCKET : -1;
|
|
|
|
int send_index = (send_recv & CURL_XFER_SEND)? FIRSTSOCKET : -1;
|
|
|
|
DEBUGASSERT((recv_index >= 0) || (recv_size == -1));
|
|
|
|
xfer_setup(data, recv_index, recv_size, getheader, send_index, FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
void Curl_xfer_setup2(struct Curl_easy *data,
|
|
|
|
int send_recv,
|
|
|
|
curl_off_t recv_size,
|
|
|
|
bool shutdown)
|
|
|
|
{
|
|
|
|
int recv_index = (send_recv & CURL_XFER_RECV)? SECONDARYSOCKET : -1;
|
|
|
|
int send_index = (send_recv & CURL_XFER_SEND)? SECONDARYSOCKET : -1;
|
|
|
|
DEBUGASSERT((recv_index >= 0) || (recv_size == -1));
|
|
|
|
xfer_setup(data, recv_index, recv_size, FALSE, send_index, shutdown);
|
|
|
|
}
|
|
|
|
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
CURLcode Curl_xfer_write_resp(struct Curl_easy *data,
|
2024-03-21 19:15:59 +08:00
|
|
|
const char *buf, size_t blen,
|
2024-03-11 19:35:07 +08:00
|
|
|
bool is_eos)
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
{
|
|
|
|
CURLcode result = CURLE_OK;
|
|
|
|
|
|
|
|
if(data->conn->handler->write_resp) {
|
|
|
|
/* protocol handlers offering this function take full responsibility
|
|
|
|
* for writing all received download data to the client. */
|
2024-03-11 19:35:07 +08:00
|
|
|
result = data->conn->handler->write_resp(data, buf, blen, is_eos);
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* No special handling by protocol handler, write all received data
|
|
|
|
* as BODY to the client. */
|
|
|
|
if(blen || is_eos) {
|
|
|
|
int cwtype = CLIENTWRITE_BODY;
|
|
|
|
if(is_eos)
|
|
|
|
cwtype |= CLIENTWRITE_EOS;
|
|
|
|
|
|
|
|
#ifndef CURL_DISABLE_POP3
|
|
|
|
if(blen && data->conn->handler->protocol & PROTO_FAMILY_POP3) {
|
|
|
|
result = data->req.ignorebody? CURLE_OK :
|
|
|
|
Curl_pop3_write(data, buf, blen);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
#endif /* CURL_DISABLE_POP3 */
|
|
|
|
result = Curl_client_write(data, cwtype, buf, blen);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if(!result && is_eos) {
|
|
|
|
/* If we wrote the EOS, we are definitely done */
|
|
|
|
data->req.eos_written = TRUE;
|
|
|
|
data->req.download_done = TRUE;
|
|
|
|
}
|
2024-03-28 21:12:54 +08:00
|
|
|
CURL_TRC_WRITE(data, "xfer_write_resp(len=%zu, eos=%d) -> %d",
|
|
|
|
blen, is_eos, result);
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
return result;
|
|
|
|
}
|
2024-02-07 19:05:05 +08:00
|
|
|
|
2024-03-21 19:15:59 +08:00
|
|
|
CURLcode Curl_xfer_write_resp_hd(struct Curl_easy *data,
|
|
|
|
const char *hd0, size_t hdlen, bool is_eos)
|
|
|
|
{
|
|
|
|
if(data->conn->handler->write_resp_hd) {
|
|
|
|
/* protocol handlers offering this function take full responsibility
|
|
|
|
* for writing all received download data to the client. */
|
|
|
|
return data->conn->handler->write_resp_hd(data, hd0, hdlen, is_eos);
|
|
|
|
}
|
|
|
|
/* No special handling by protocol handler, write as response bytes */
|
|
|
|
return Curl_xfer_write_resp(data, hd0, hdlen, is_eos);
|
|
|
|
}
|
|
|
|
|
2024-02-07 19:05:05 +08:00
|
|
|
CURLcode Curl_xfer_write_done(struct Curl_easy *data, bool premature)
|
|
|
|
{
|
|
|
|
(void)premature;
|
|
|
|
return Curl_cw_out_done(data);
|
|
|
|
}
|
2024-02-14 19:09:32 +08:00
|
|
|
|
|
|
|
CURLcode Curl_xfer_send(struct Curl_easy *data,
|
|
|
|
const void *buf, size_t blen,
|
lib: Curl_read/Curl_write clarifications
- replace `Curl_read()`, `Curl_write()` and `Curl_nwrite()` to
clarify when and at what level they operate
- send/recv of transfer related data is now done via
`Curl_xfer_send()/Curl_xfer_recv()` which no longer has
socket/socketindex as parameter. It decides on the transfer
setup of `conn->sockfd` and `conn->writesockfd` on which
connection filter chain to operate.
- send/recv on a specific connection filter chain is done via
`Curl_conn_send()/Curl_conn_recv()` which get the socket index
as parameter.
- rename `Curl_setup_transfer()` to `Curl_xfer_setup()` for
naming consistency
- clarify that the special CURLE_AGAIN hangling to return
`CURLE_OK` with length 0 only applies to `Curl_xfer_send()`
and CURLE_AGAIN is returned by all other send() variants.
- fix a bug in websocket `curl_ws_recv()` that mixed up data
when it arrived in more than a single chunk
The method for sending not just raw bytes, but bytes that are either
"headers" or "body". The send abstraction stack, to to bottom, now is:
* `Curl_req_send()`: has parameter to indicate amount of header bytes,
buffers all data.
* `Curl_xfer_send()`: knows on which socket index to send, returns
amount of bytes sent.
* `Curl_conn_send()`: called with socket index, returns amount of bytes
sent.
In addition there is `Curl_req_flush()` for writing out all buffered
bytes.
`Curl_req_send()` is active for requests without body,
`Curl_buffer_send()` still being used for others. This is because the
special quirks need to be addressed in future parts:
* `expect-100` handling
* `Curl_fillreadbuffer()` needs to add directly to the new
`data->req.sendbuf`
* special body handlings, like `chunked` encodings and line end
conversions will be moved into something like a Client Reader.
In functions of the pattern `CURLcode xxx_send(..., ssize_t *written)`,
replace the `ssize_t` with a `size_t`. It makes no sense to allow for negative
values as the returned `CURLcode` already specifies error conditions. This
allows easier handling of lengths without casting.
Closes #12964
2024-02-15 23:22:53 +08:00
|
|
|
size_t *pnwritten)
|
2024-02-14 19:09:32 +08:00
|
|
|
{
|
|
|
|
CURLcode result;
|
|
|
|
int sockindex;
|
|
|
|
|
|
|
|
if(!data || !data->conn)
|
|
|
|
return CURLE_FAILED_INIT;
|
|
|
|
/* FIXME: would like to enable this, but some protocols (MQTT) do not
|
|
|
|
* setup the transfer correctly, it seems
|
|
|
|
if(data->conn->writesockfd == CURL_SOCKET_BAD) {
|
|
|
|
failf(data, "transfer not setup for sending");
|
|
|
|
DEBUGASSERT(0);
|
|
|
|
return CURLE_SEND_ERROR;
|
|
|
|
} */
|
|
|
|
sockindex = ((data->conn->writesockfd != CURL_SOCKET_BAD) &&
|
|
|
|
(data->conn->writesockfd == data->conn->sock[SECONDARYSOCKET]));
|
|
|
|
result = Curl_conn_send(data, sockindex, buf, blen, pnwritten);
|
|
|
|
if(result == CURLE_AGAIN) {
|
|
|
|
result = CURLE_OK;
|
|
|
|
*pnwritten = 0;
|
|
|
|
}
|
2024-04-04 17:06:06 +08:00
|
|
|
else if(!result && *pnwritten)
|
|
|
|
data->info.request_size += *pnwritten;
|
|
|
|
|
2024-02-14 19:09:32 +08:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
CURLcode Curl_xfer_recv(struct Curl_easy *data,
|
|
|
|
char *buf, size_t blen,
|
|
|
|
ssize_t *pnrcvd)
|
|
|
|
{
|
|
|
|
int sockindex;
|
|
|
|
|
|
|
|
if(!data || !data->conn)
|
|
|
|
return CURLE_FAILED_INIT;
|
|
|
|
/* FIXME: would like to enable this, but some protocols (MQTT) do not
|
|
|
|
* setup the transfer correctly, it seems
|
|
|
|
if(data->conn->sockfd == CURL_SOCKET_BAD) {
|
|
|
|
failf(data, "transfer not setup for receiving");
|
|
|
|
DEBUGASSERT(0);
|
|
|
|
return CURLE_RECV_ERROR;
|
|
|
|
} */
|
|
|
|
sockindex = ((data->conn->sockfd != CURL_SOCKET_BAD) &&
|
|
|
|
(data->conn->sockfd == data->conn->sock[SECONDARYSOCKET]));
|
|
|
|
if(data->set.buffer_size > 0 && (size_t)data->set.buffer_size < blen)
|
|
|
|
blen = (size_t)data->set.buffer_size;
|
|
|
|
return Curl_conn_recv(data, sockindex, buf, blen, pnrcvd);
|
|
|
|
}
|
2024-02-28 21:51:53 +08:00
|
|
|
|
|
|
|
CURLcode Curl_xfer_send_close(struct Curl_easy *data)
|
|
|
|
{
|
|
|
|
Curl_conn_ev_data_done_send(data);
|
|
|
|
return CURLE_OK;
|
|
|
|
}
|
2024-06-10 19:32:13 +08:00
|
|
|
|
|
|
|
CURLcode Curl_xfer_send_shutdown(struct Curl_easy *data, bool *done)
|
|
|
|
{
|
|
|
|
int sockindex;
|
|
|
|
|
|
|
|
if(!data || !data->conn)
|
|
|
|
return CURLE_FAILED_INIT;
|
|
|
|
if(data->conn->writesockfd == CURL_SOCKET_BAD)
|
|
|
|
return CURLE_FAILED_INIT;
|
|
|
|
sockindex = (data->conn->writesockfd == data->conn->sock[SECONDARYSOCKET]);
|
|
|
|
return Curl_conn_shutdown(data, sockindex, done);
|
|
|
|
}
|
2024-06-07 20:38:51 +08:00
|
|
|
|
|
|
|
bool Curl_xfer_is_blocked(struct Curl_easy *data)
|
|
|
|
{
|
|
|
|
bool want_send = ((data)->req.keepon & KEEP_SEND);
|
|
|
|
bool want_recv = ((data)->req.keepon & KEEP_RECV);
|
|
|
|
if(!want_send)
|
|
|
|
return (want_recv && Curl_cwriter_is_paused(data));
|
|
|
|
else if(!want_recv)
|
|
|
|
return (want_send && Curl_creader_is_paused(data));
|
|
|
|
else
|
|
|
|
return Curl_creader_is_paused(data) && Curl_cwriter_is_paused(data);
|
|
|
|
}
|