2002-09-03 19:52:59 +08:00
|
|
|
/***************************************************************************
|
2005-03-04 08:14:45 +08:00
|
|
|
* _ _ ____ _
|
|
|
|
* Project ___| | | | _ \| |
|
|
|
|
* / __| | | | |_) | |
|
|
|
|
* | (__| |_| | _ <| |___
|
2001-03-08 07:28:22 +08:00
|
|
|
* \___|\___/|_| \_\_____|
|
|
|
|
*
|
2023-01-02 20:51:48 +08:00
|
|
|
* Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
2001-03-08 07:28:22 +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.
|
2005-03-04 08:14:45 +08:00
|
|
|
*
|
2001-03-08 07:28:22 +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.
|
2001-03-08 07:28:22 +08:00
|
|
|
*
|
|
|
|
* This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY
|
|
|
|
* KIND, either express or implied.
|
|
|
|
*
|
2002-09-03 19:52:59 +08:00
|
|
|
* SPDX-License-Identifier: curl
|
2022-05-17 17:16:50 +08:00
|
|
|
*
|
2002-09-03 19:52:59 +08:00
|
|
|
***************************************************************************/
|
2011-07-26 23:23:27 +08:00
|
|
|
|
2013-01-07 02:06:49 +08:00
|
|
|
#include "curl_setup.h"
|
2001-03-08 07:28:22 +08:00
|
|
|
|
2002-06-11 19:13:01 +08:00
|
|
|
#ifndef CURL_DISABLE_HTTP
|
2001-03-08 07:28:22 +08:00
|
|
|
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "urldata.h" /* it includes http_chunks.h */
|
2024-02-15 23:22:53 +08:00
|
|
|
#include "curl_printf.h"
|
2024-03-28 21:12:54 +08:00
|
|
|
#include "curl_trc.h"
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "sendf.h" /* for the client write stuff */
|
2020-06-05 20:04:22 +08:00
|
|
|
#include "dynbuf.h"
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "content_encoding.h"
|
|
|
|
#include "http.h"
|
2024-02-15 23:22:53 +08:00
|
|
|
#include "multiif.h"
|
2014-01-17 06:07:54 +08:00
|
|
|
#include "strtoofft.h"
|
2014-01-19 21:04:59 +08:00
|
|
|
#include "warnless.h"
|
2002-09-03 06:31:18 +08:00
|
|
|
|
2015-03-25 06:12:03 +08:00
|
|
|
/* The last #include files should be: */
|
|
|
|
#include "curl_memory.h"
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "memdebug.h"
|
2001-03-08 07:28:22 +08:00
|
|
|
|
2005-03-04 08:14:45 +08:00
|
|
|
/*
|
2001-03-08 07:28:22 +08:00
|
|
|
* Chunk format (simplified):
|
|
|
|
*
|
|
|
|
* <HEX SIZE>[ chunk extension ] CRLF
|
2001-09-03 20:51:23 +08:00
|
|
|
* <DATA> CRLF
|
2001-03-08 07:28:22 +08:00
|
|
|
*
|
|
|
|
* Highlights from RFC2616 section 3.6 say:
|
|
|
|
|
|
|
|
The chunked encoding modifies the body of a message in order to
|
|
|
|
transfer it as a series of chunks, each with its own size indicator,
|
|
|
|
followed by an OPTIONAL trailer containing entity-header fields. This
|
|
|
|
allows dynamically produced content to be transferred along with the
|
|
|
|
information necessary for the recipient to verify that it has
|
|
|
|
received the full message.
|
|
|
|
|
|
|
|
Chunked-Body = *chunk
|
|
|
|
last-chunk
|
|
|
|
trailer
|
|
|
|
CRLF
|
|
|
|
|
|
|
|
chunk = chunk-size [ chunk-extension ] CRLF
|
|
|
|
chunk-data CRLF
|
|
|
|
chunk-size = 1*HEX
|
|
|
|
last-chunk = 1*("0") [ chunk-extension ] CRLF
|
|
|
|
|
|
|
|
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
|
|
|
|
chunk-ext-name = token
|
|
|
|
chunk-ext-val = token | quoted-string
|
|
|
|
chunk-data = chunk-size(OCTET)
|
|
|
|
trailer = *(entity-header CRLF)
|
|
|
|
|
|
|
|
The chunk-size field is a string of hex digits indicating the size of
|
|
|
|
the chunk. The chunked encoding is ended by any chunk whose size is
|
|
|
|
zero, followed by the trailer, which is terminated by an empty line.
|
|
|
|
|
|
|
|
*/
|
|
|
|
|
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
|
|
|
void Curl_httpchunk_init(struct Curl_easy *data, struct Curl_chunker *ch,
|
|
|
|
bool ignore_body)
|
2001-03-08 07:28:22 +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
|
|
|
(void)data;
|
|
|
|
ch->hexindex = 0; /* start at 0 */
|
|
|
|
ch->state = CHUNK_HEX; /* we get hex first! */
|
|
|
|
ch->last_code = CHUNKE_OK;
|
|
|
|
Curl_dyn_init(&ch->trailer, DYN_H1_TRAILER);
|
|
|
|
ch->ignore_body = ignore_body;
|
2001-03-08 07:28:22 +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
|
|
|
void Curl_httpchunk_reset(struct Curl_easy *data, struct Curl_chunker *ch,
|
|
|
|
bool ignore_body)
|
|
|
|
{
|
|
|
|
(void)data;
|
|
|
|
ch->hexindex = 0; /* start at 0 */
|
|
|
|
ch->state = CHUNK_HEX; /* we get hex first! */
|
|
|
|
ch->last_code = CHUNKE_OK;
|
|
|
|
Curl_dyn_reset(&ch->trailer);
|
|
|
|
ch->ignore_body = ignore_body;
|
|
|
|
}
|
|
|
|
|
|
|
|
void Curl_httpchunk_free(struct Curl_easy *data, struct Curl_chunker *ch)
|
|
|
|
{
|
|
|
|
(void)data;
|
|
|
|
Curl_dyn_free(&ch->trailer);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Curl_httpchunk_is_done(struct Curl_easy *data, struct Curl_chunker *ch)
|
|
|
|
{
|
|
|
|
(void)data;
|
|
|
|
return ch->state == CHUNK_DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static CURLcode httpchunk_readwrite(struct Curl_easy *data,
|
|
|
|
struct Curl_chunker *ch,
|
|
|
|
struct Curl_cwriter *cw_next,
|
|
|
|
const char *buf, size_t blen,
|
|
|
|
size_t *pconsumed)
|
2001-03-08 07:28:22 +08:00
|
|
|
{
|
2017-09-10 05:09:06 +08:00
|
|
|
CURLcode result = CURLE_OK;
|
2004-03-04 23:25:06 +08:00
|
|
|
size_t piece;
|
|
|
|
|
2023-11-07 00:06:06 +08:00
|
|
|
*pconsumed = 0; /* nothing's written yet */
|
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
|
|
|
/* first check terminal states that will not progress anywhere */
|
|
|
|
if(ch->state == CHUNK_DONE)
|
|
|
|
return CURLE_OK;
|
|
|
|
if(ch->state == CHUNK_FAILED)
|
|
|
|
return CURLE_RECV_ERROR;
|
2001-03-08 07:28:22 +08:00
|
|
|
|
2007-02-13 05:13:47 +08:00
|
|
|
/* the original data is written to the client, but we go on with the
|
2022-10-31 00:38:16 +08:00
|
|
|
chunk read process, to properly calculate the content length */
|
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(data->set.http_te_skip && !ch->ignore_body) {
|
|
|
|
if(cw_next)
|
|
|
|
result = Curl_cwriter_write(data, cw_next, CLIENTWRITE_BODY, buf, blen);
|
|
|
|
else
|
|
|
|
result = Curl_client_write(data, CLIENTWRITE_BODY, (char *)buf, blen);
|
2019-10-01 21:40:05 +08:00
|
|
|
if(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
|
|
|
ch->state = CHUNK_FAILED;
|
|
|
|
ch->last_code = CHUNKE_PASSTHRU_ERROR;
|
|
|
|
return result;
|
2019-10-01 21:40:05 +08:00
|
|
|
}
|
2008-01-03 06:30:34 +08:00
|
|
|
}
|
2007-02-13 05:13:47 +08:00
|
|
|
|
2023-11-07 00:06:06 +08:00
|
|
|
while(blen) {
|
2001-03-08 07:28:22 +08:00
|
|
|
switch(ch->state) {
|
|
|
|
case CHUNK_HEX:
|
2023-11-07 00:06:06 +08:00
|
|
|
if(ISXDIGIT(*buf)) {
|
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(ch->hexindex >= CHUNK_MAXNUM_LEN) {
|
|
|
|
failf(data, "chunk hex-length longer than %d", CHUNK_MAXNUM_LEN);
|
|
|
|
ch->state = CHUNK_FAILED;
|
|
|
|
ch->last_code = CHUNKE_TOO_LONG_HEX; /* longer than we support */
|
|
|
|
return CURLE_RECV_ERROR;
|
2001-03-08 07:28:22 +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
|
|
|
ch->hexbuffer[ch->hexindex++] = *buf;
|
|
|
|
buf++;
|
|
|
|
blen--;
|
2024-02-14 23:27:23 +08:00
|
|
|
(*pconsumed)++;
|
2001-03-08 07:28:22 +08:00
|
|
|
}
|
|
|
|
else {
|
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(0 == ch->hexindex) {
|
2001-03-12 23:20:35 +08:00
|
|
|
/* This is illegal data, we received junk where we expected
|
|
|
|
a hexadecimal digit. */
|
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
|
|
|
failf(data, "chunk hex-length char not a hex digit: 0x%x", *buf);
|
|
|
|
ch->state = CHUNK_FAILED;
|
|
|
|
ch->last_code = CHUNKE_ILLEGAL_HEX;
|
|
|
|
return CURLE_RECV_ERROR;
|
|
|
|
}
|
2014-01-17 07:34:36 +08:00
|
|
|
|
2023-11-07 00:06:06 +08:00
|
|
|
/* blen and buf are unmodified */
|
2017-09-10 05:09:06 +08:00
|
|
|
ch->hexbuffer[ch->hexindex] = 0;
|
2024-02-26 19:27:07 +08:00
|
|
|
if(curlx_strtoofft(ch->hexbuffer, NULL, 16, &ch->datasize)) {
|
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
|
|
|
failf(data, "chunk hex-length not valid: '%s'", ch->hexbuffer);
|
|
|
|
ch->state = CHUNK_FAILED;
|
|
|
|
ch->last_code = CHUNKE_ILLEGAL_HEX;
|
|
|
|
return CURLE_RECV_ERROR;
|
|
|
|
}
|
2014-01-17 07:34:36 +08:00
|
|
|
ch->state = CHUNK_LF; /* now wait for the CRLF */
|
2001-03-08 07:28:22 +08:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2014-01-17 07:34:36 +08:00
|
|
|
case CHUNK_LF:
|
|
|
|
/* waiting for the LF after a chunk size */
|
2023-11-07 00:06:06 +08:00
|
|
|
if(*buf == 0x0a) {
|
2001-03-08 07:28:22 +08:00
|
|
|
/* we're now expecting data to come, unless size was zero! */
|
|
|
|
if(0 == ch->datasize) {
|
2010-08-25 19:42:14 +08:00
|
|
|
ch->state = CHUNK_TRAILER; /* now check for trailers */
|
2001-03-08 07:28:22 +08:00
|
|
|
}
|
2024-03-28 21:12:54 +08:00
|
|
|
else {
|
2001-03-08 07:28:22 +08:00
|
|
|
ch->state = CHUNK_DATA;
|
2024-03-28 21:12:54 +08:00
|
|
|
CURL_TRC_WRITE(data, "http_chunked, chunk start of %"
|
|
|
|
CURL_FORMAT_CURL_OFF_T " bytes", ch->datasize);
|
|
|
|
}
|
2001-03-08 07:28:22 +08:00
|
|
|
}
|
2014-01-17 07:34:36 +08:00
|
|
|
|
2023-11-07 00:06:06 +08:00
|
|
|
buf++;
|
|
|
|
blen--;
|
2024-02-14 23:27:23 +08:00
|
|
|
(*pconsumed)++;
|
2001-03-08 07:28:22 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case CHUNK_DATA:
|
2023-11-07 00:06:06 +08:00
|
|
|
/* We expect 'datasize' of data. We have 'blen' right now, it can be
|
2014-01-17 07:34:36 +08:00
|
|
|
more or less than 'datasize'. Get the smallest piece.
|
2001-03-08 07:28:22 +08:00
|
|
|
*/
|
2023-11-07 00:06:06 +08:00
|
|
|
piece = blen;
|
|
|
|
if(ch->datasize < (curl_off_t)blen)
|
|
|
|
piece = curlx_sotouz(ch->datasize);
|
2001-03-08 07:28:22 +08:00
|
|
|
|
|
|
|
/* Write the data portion available */
|
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(!data->set.http_te_skip && !ch->ignore_body) {
|
|
|
|
if(cw_next)
|
|
|
|
result = Curl_cwriter_write(data, cw_next, CLIENTWRITE_BODY,
|
|
|
|
buf, piece);
|
|
|
|
else
|
|
|
|
result = Curl_client_write(data, CLIENTWRITE_BODY,
|
|
|
|
(char *)buf, piece);
|
2019-10-01 21:40:05 +08:00
|
|
|
if(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
|
|
|
ch->state = CHUNK_FAILED;
|
|
|
|
ch->last_code = CHUNKE_PASSTHRU_ERROR;
|
|
|
|
return result;
|
2019-10-01 21:40:05 +08:00
|
|
|
}
|
2018-02-12 10:38:18 +08:00
|
|
|
}
|
2004-03-04 23:25:06 +08:00
|
|
|
|
2023-11-07 00:06:06 +08:00
|
|
|
*pconsumed += piece;
|
2001-03-08 07:28:22 +08:00
|
|
|
ch->datasize -= piece; /* decrease amount left to expect */
|
2023-11-07 00:06:06 +08:00
|
|
|
buf += piece; /* move read pointer forward */
|
|
|
|
blen -= piece; /* decrease space left in this round */
|
2024-03-28 21:12:54 +08:00
|
|
|
CURL_TRC_WRITE(data, "http_chunked, write %zu body bytes, %"
|
|
|
|
CURL_FORMAT_CURL_OFF_T " bytes in chunk remain",
|
|
|
|
piece, ch->datasize);
|
2001-03-08 07:28:22 +08:00
|
|
|
|
|
|
|
if(0 == ch->datasize)
|
2001-03-14 06:16:42 +08:00
|
|
|
/* end of data this round, we now expect a trailing CRLF */
|
|
|
|
ch->state = CHUNK_POSTLF;
|
|
|
|
break;
|
2001-03-08 07:28:22 +08:00
|
|
|
|
2001-03-14 06:16:42 +08:00
|
|
|
case CHUNK_POSTLF:
|
2023-11-07 00:06:06 +08:00
|
|
|
if(*buf == 0x0a) {
|
2014-01-17 07:34:36 +08:00
|
|
|
/* The last one before we go back to hex state and start all over. */
|
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
|
|
|
Curl_httpchunk_reset(data, ch, ch->ignore_body);
|
|
|
|
}
|
|
|
|
else if(*buf != 0x0d) {
|
|
|
|
ch->state = CHUNK_FAILED;
|
|
|
|
ch->last_code = CHUNKE_BAD_CHUNK;
|
|
|
|
return CURLE_RECV_ERROR;
|
2001-03-14 06:16:42 +08:00
|
|
|
}
|
2023-11-07 00:06:06 +08:00
|
|
|
buf++;
|
|
|
|
blen--;
|
2024-02-14 23:27:23 +08:00
|
|
|
(*pconsumed)++;
|
2001-03-08 07:28:22 +08:00
|
|
|
break;
|
2001-03-14 06:16:42 +08:00
|
|
|
|
2005-07-13 02:15:34 +08:00
|
|
|
case CHUNK_TRAILER:
|
2023-11-07 00:06:06 +08:00
|
|
|
if((*buf == 0x0d) || (*buf == 0x0a)) {
|
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
|
|
|
char *tr = Curl_dyn_ptr(&ch->trailer);
|
2010-08-25 19:42:14 +08:00
|
|
|
/* this is the end of a trailer, but if the trailer was zero bytes
|
|
|
|
there was no trailer and we move on */
|
2007-02-22 05:59:40 +08:00
|
|
|
|
2020-06-05 20:04:22 +08:00
|
|
|
if(tr) {
|
|
|
|
size_t trlen;
|
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
|
|
|
result = Curl_dyn_addn(&ch->trailer, (char *)STRCONST("\x0d\x0a"));
|
|
|
|
if(result) {
|
|
|
|
ch->state = CHUNK_FAILED;
|
|
|
|
ch->last_code = CHUNKE_OUT_OF_MEMORY;
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
tr = Curl_dyn_ptr(&ch->trailer);
|
|
|
|
trlen = Curl_dyn_len(&ch->trailer);
|
2008-01-03 06:30:34 +08:00
|
|
|
if(!data->set.http_te_skip) {
|
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(cw_next)
|
|
|
|
result = Curl_cwriter_write(data, cw_next,
|
|
|
|
CLIENTWRITE_HEADER|
|
|
|
|
CLIENTWRITE_TRAILER,
|
|
|
|
tr, trlen);
|
|
|
|
else
|
|
|
|
result = Curl_client_write(data,
|
|
|
|
CLIENTWRITE_HEADER|
|
|
|
|
CLIENTWRITE_TRAILER,
|
|
|
|
tr, trlen);
|
2019-10-01 21:40:05 +08:00
|
|
|
if(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
|
|
|
ch->state = CHUNK_FAILED;
|
|
|
|
ch->last_code = CHUNKE_PASSTHRU_ERROR;
|
|
|
|
return result;
|
2019-10-01 21:40:05 +08:00
|
|
|
}
|
2008-01-03 06:30: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
|
|
|
Curl_dyn_reset(&ch->trailer);
|
2010-08-25 19:42:14 +08:00
|
|
|
ch->state = CHUNK_TRAILER_CR;
|
2023-11-07 00:06:06 +08:00
|
|
|
if(*buf == 0x0a)
|
2014-01-17 07:34:36 +08:00
|
|
|
/* already on the LF */
|
|
|
|
break;
|
2005-07-13 02:15:34 +08:00
|
|
|
}
|
2010-08-25 19:42:14 +08:00
|
|
|
else {
|
|
|
|
/* no trailer, we're on the final CRLF pair */
|
|
|
|
ch->state = CHUNK_TRAILER_POSTCR;
|
|
|
|
break; /* don't advance the pointer */
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else {
|
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
|
|
|
result = Curl_dyn_addn(&ch->trailer, buf, 1);
|
|
|
|
if(result) {
|
|
|
|
ch->state = CHUNK_FAILED;
|
|
|
|
ch->last_code = CHUNKE_OUT_OF_MEMORY;
|
|
|
|
return result;
|
|
|
|
}
|
2010-08-25 19:42:14 +08:00
|
|
|
}
|
2023-11-07 00:06:06 +08:00
|
|
|
buf++;
|
|
|
|
blen--;
|
2024-02-14 23:27:23 +08:00
|
|
|
(*pconsumed)++;
|
2010-08-25 19:42:14 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case CHUNK_TRAILER_CR:
|
2023-11-07 00:06:06 +08:00
|
|
|
if(*buf == 0x0a) {
|
2010-08-25 19:42:14 +08:00
|
|
|
ch->state = CHUNK_TRAILER_POSTCR;
|
2023-11-07 00:06:06 +08:00
|
|
|
buf++;
|
|
|
|
blen--;
|
2024-02-14 23:27:23 +08:00
|
|
|
(*pconsumed)++;
|
2005-07-13 02:15: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
|
|
|
else {
|
|
|
|
ch->state = CHUNK_FAILED;
|
|
|
|
ch->last_code = CHUNKE_BAD_CHUNK;
|
|
|
|
return CURLE_RECV_ERROR;
|
|
|
|
}
|
2005-07-13 02:15:34 +08:00
|
|
|
break;
|
|
|
|
|
2010-08-25 19:42:14 +08:00
|
|
|
case CHUNK_TRAILER_POSTCR:
|
|
|
|
/* We enter this state when a CR should arrive so we expect to
|
|
|
|
have to first pass a CR before we wait for LF */
|
2023-11-07 00:06:06 +08:00
|
|
|
if((*buf != 0x0d) && (*buf != 0x0a)) {
|
2010-08-25 19:42:14 +08:00
|
|
|
/* not a CR then it must be another header in the trailer */
|
|
|
|
ch->state = CHUNK_TRAILER;
|
|
|
|
break;
|
|
|
|
}
|
2023-11-07 00:06:06 +08:00
|
|
|
if(*buf == 0x0d) {
|
2014-01-17 07:34:36 +08:00
|
|
|
/* skip if CR */
|
2023-11-07 00:06:06 +08:00
|
|
|
buf++;
|
|
|
|
blen--;
|
2024-02-14 23:27:23 +08:00
|
|
|
(*pconsumed)++;
|
2007-02-22 05:59:40 +08:00
|
|
|
}
|
2014-01-17 07:34:36 +08:00
|
|
|
/* now wait for the final LF */
|
|
|
|
ch->state = CHUNK_STOP;
|
2007-02-22 05:59:40 +08:00
|
|
|
break;
|
|
|
|
|
2001-03-08 07:28:22 +08:00
|
|
|
case CHUNK_STOP:
|
2023-11-07 00:06:06 +08:00
|
|
|
if(*buf == 0x0a) {
|
|
|
|
blen--;
|
2024-02-14 23:27:23 +08:00
|
|
|
(*pconsumed)++;
|
2007-02-22 05:59:40 +08:00
|
|
|
/* Record the length of any data left in the end of the buffer
|
|
|
|
even if there's no more chunks to read */
|
2023-11-07 00:06:06 +08:00
|
|
|
ch->datasize = blen;
|
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
|
|
|
ch->state = CHUNK_DONE;
|
2024-03-28 21:12:54 +08:00
|
|
|
CURL_TRC_WRITE(data, "http_chunk, response complete");
|
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 CURLE_OK;
|
2007-02-22 05:59:40 +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
|
|
|
else {
|
|
|
|
ch->state = CHUNK_FAILED;
|
|
|
|
ch->last_code = CHUNKE_BAD_CHUNK;
|
2024-03-28 21:12:54 +08:00
|
|
|
CURL_TRC_WRITE(data, "http_chunk error, expected 0x0a, seeing 0x%ux",
|
|
|
|
(unsigned int)*buf);
|
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 CURLE_RECV_ERROR;
|
|
|
|
}
|
|
|
|
case CHUNK_DONE:
|
|
|
|
return CURLE_OK;
|
|
|
|
|
|
|
|
case CHUNK_FAILED:
|
|
|
|
return CURLE_RECV_ERROR;
|
2001-03-08 07:28:22 +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
|
|
|
|
2001-03-08 07:28:22 +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
|
|
|
return CURLE_OK;
|
2001-03-08 07:28:22 +08:00
|
|
|
}
|
2014-03-14 22:44:18 +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
|
|
|
static const char *Curl_chunked_strerror(CHUNKcode code)
|
2014-03-14 22:44:18 +08:00
|
|
|
{
|
2016-12-14 06:34:59 +08:00
|
|
|
switch(code) {
|
2014-03-14 22:44:18 +08:00
|
|
|
default:
|
|
|
|
return "OK";
|
|
|
|
case CHUNKE_TOO_LONG_HEX:
|
|
|
|
return "Too long hexadecimal number";
|
|
|
|
case CHUNKE_ILLEGAL_HEX:
|
|
|
|
return "Illegal or missing hexadecimal sequence";
|
|
|
|
case CHUNKE_BAD_CHUNK:
|
|
|
|
return "Malformed encoding found";
|
2019-10-01 21:40:05 +08:00
|
|
|
case CHUNKE_PASSTHRU_ERROR:
|
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 "Error writing data to client";
|
2014-03-14 22:44:18 +08:00
|
|
|
case CHUNKE_BAD_ENCODING:
|
|
|
|
return "Bad content-encoding found";
|
|
|
|
case CHUNKE_OUT_OF_MEMORY:
|
|
|
|
return "Out of memory";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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_httpchunk_read(struct Curl_easy *data,
|
|
|
|
struct Curl_chunker *ch,
|
|
|
|
char *buf, size_t blen,
|
|
|
|
size_t *pconsumed)
|
|
|
|
{
|
|
|
|
return httpchunk_readwrite(data, ch, NULL, buf, blen, pconsumed);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct chunked_writer {
|
|
|
|
struct Curl_cwriter super;
|
|
|
|
struct Curl_chunker ch;
|
|
|
|
};
|
|
|
|
|
|
|
|
static CURLcode cw_chunked_init(struct Curl_easy *data,
|
|
|
|
struct Curl_cwriter *writer)
|
|
|
|
{
|
2024-03-06 16:52:43 +08:00
|
|
|
struct chunked_writer *ctx = writer->ctx;
|
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
|
|
|
|
|
|
|
data->req.chunk = TRUE; /* chunks coming our way. */
|
|
|
|
Curl_httpchunk_init(data, &ctx->ch, FALSE);
|
|
|
|
return CURLE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cw_chunked_close(struct Curl_easy *data,
|
|
|
|
struct Curl_cwriter *writer)
|
|
|
|
{
|
2024-03-06 16:52:43 +08:00
|
|
|
struct chunked_writer *ctx = writer->ctx;
|
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
|
|
|
Curl_httpchunk_free(data, &ctx->ch);
|
|
|
|
}
|
|
|
|
|
|
|
|
static CURLcode cw_chunked_write(struct Curl_easy *data,
|
|
|
|
struct Curl_cwriter *writer, int type,
|
|
|
|
const char *buf, size_t blen)
|
|
|
|
{
|
2024-03-06 16:52:43 +08:00
|
|
|
struct chunked_writer *ctx = writer->ctx;
|
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;
|
|
|
|
size_t consumed;
|
|
|
|
|
|
|
|
if(!(type & CLIENTWRITE_BODY))
|
|
|
|
return Curl_cwriter_write(data, writer->next, type, buf, blen);
|
|
|
|
|
|
|
|
consumed = 0;
|
|
|
|
result = httpchunk_readwrite(data, &ctx->ch, writer->next, buf, blen,
|
|
|
|
&consumed);
|
|
|
|
|
|
|
|
if(result) {
|
|
|
|
if(CHUNKE_PASSTHRU_ERROR == ctx->ch.last_code) {
|
|
|
|
failf(data, "Failed reading the chunked-encoded stream");
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
failf(data, "%s in chunked-encoding",
|
|
|
|
Curl_chunked_strerror(ctx->ch.last_code));
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
blen -= consumed;
|
|
|
|
if(CHUNK_DONE == ctx->ch.state) {
|
|
|
|
/* chunks read successfully, download is complete */
|
|
|
|
data->req.download_done = TRUE;
|
|
|
|
if(blen) {
|
|
|
|
infof(data, "Leftovers after chunking: %zu bytes", blen);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else if((type & CLIENTWRITE_EOS) && !data->req.no_body) {
|
|
|
|
failf(data, "transfer closed with outstanding read data remaining");
|
|
|
|
return CURLE_PARTIAL_FILE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return CURLE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* HTTP chunked Transfer-Encoding decoder */
|
|
|
|
const struct Curl_cwtype Curl_httpchunk_unencoder = {
|
|
|
|
"chunked",
|
|
|
|
NULL,
|
|
|
|
cw_chunked_init,
|
|
|
|
cw_chunked_write,
|
|
|
|
cw_chunked_close,
|
|
|
|
sizeof(struct chunked_writer)
|
|
|
|
};
|
|
|
|
|
2024-02-15 23:22:53 +08:00
|
|
|
/* max length of a HTTP chunk that we want to generate */
|
|
|
|
#define CURL_CHUNKED_MINLEN (1024)
|
|
|
|
#define CURL_CHUNKED_MAXLEN (64 * 1024)
|
|
|
|
|
|
|
|
struct chunked_reader {
|
|
|
|
struct Curl_creader super;
|
|
|
|
struct bufq chunkbuf;
|
|
|
|
BIT(read_eos); /* we read an EOS from the next reader */
|
|
|
|
BIT(eos); /* we have returned an EOS */
|
|
|
|
};
|
|
|
|
|
|
|
|
static CURLcode cr_chunked_init(struct Curl_easy *data,
|
|
|
|
struct Curl_creader *reader)
|
|
|
|
{
|
2024-03-06 16:52:43 +08:00
|
|
|
struct chunked_reader *ctx = reader->ctx;
|
2024-02-15 23:22:53 +08:00
|
|
|
(void)data;
|
|
|
|
Curl_bufq_init2(&ctx->chunkbuf, CURL_CHUNKED_MAXLEN, 2, BUFQ_OPT_SOFT_LIMIT);
|
|
|
|
return CURLE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cr_chunked_close(struct Curl_easy *data,
|
|
|
|
struct Curl_creader *reader)
|
|
|
|
{
|
2024-03-06 16:52:43 +08:00
|
|
|
struct chunked_reader *ctx = reader->ctx;
|
2024-02-15 23:22:53 +08:00
|
|
|
(void)data;
|
|
|
|
Curl_bufq_free(&ctx->chunkbuf);
|
|
|
|
}
|
|
|
|
|
|
|
|
static CURLcode add_last_chunk(struct Curl_easy *data,
|
|
|
|
struct Curl_creader *reader)
|
|
|
|
{
|
2024-03-06 16:52:43 +08:00
|
|
|
struct chunked_reader *ctx = reader->ctx;
|
2024-02-15 23:22:53 +08:00
|
|
|
struct curl_slist *trailers = NULL, *tr;
|
|
|
|
CURLcode result;
|
|
|
|
size_t n;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
if(!data->set.trailer_callback) {
|
2024-03-28 21:12:54 +08:00
|
|
|
CURL_TRC_READ(data, "http_chunk, added last, empty chunk");
|
2024-02-15 23:22:53 +08:00
|
|
|
return Curl_bufq_cwrite(&ctx->chunkbuf, STRCONST("0\r\n\r\n"), &n);
|
|
|
|
}
|
|
|
|
|
|
|
|
result = Curl_bufq_cwrite(&ctx->chunkbuf, STRCONST("0\r\n"), &n);
|
|
|
|
if(result)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
Curl_set_in_callback(data, true);
|
|
|
|
rc = data->set.trailer_callback(&trailers, data->set.trailer_data);
|
|
|
|
Curl_set_in_callback(data, false);
|
|
|
|
|
|
|
|
if(rc != CURL_TRAILERFUNC_OK) {
|
|
|
|
failf(data, "operation aborted by trailing headers callback");
|
|
|
|
result = CURLE_ABORTED_BY_CALLBACK;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
for(tr = trailers; tr; tr = tr->next) {
|
|
|
|
/* only add correctly formatted trailers */
|
|
|
|
char *ptr = strchr(tr->data, ':');
|
|
|
|
if(!ptr || *(ptr + 1) != ' ') {
|
|
|
|
infof(data, "Malformatted trailing header, skipping trailer");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
result = Curl_bufq_cwrite(&ctx->chunkbuf, tr->data,
|
|
|
|
strlen(tr->data), &n);
|
|
|
|
if(!result)
|
|
|
|
result = Curl_bufq_cwrite(&ctx->chunkbuf, STRCONST("\r\n"), &n);
|
|
|
|
if(result)
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
result = Curl_bufq_cwrite(&ctx->chunkbuf, STRCONST("\r\n"), &n);
|
|
|
|
|
|
|
|
out:
|
|
|
|
curl_slist_free_all(trailers);
|
2024-03-28 21:12:54 +08:00
|
|
|
CURL_TRC_READ(data, "http_chunk, added last chunk with trailers "
|
|
|
|
"from client -> %d", result);
|
2024-02-15 23:22:53 +08:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
static CURLcode add_chunk(struct Curl_easy *data,
|
|
|
|
struct Curl_creader *reader,
|
|
|
|
char *buf, size_t blen)
|
|
|
|
{
|
2024-03-06 16:52:43 +08:00
|
|
|
struct chunked_reader *ctx = reader->ctx;
|
2024-02-15 23:22:53 +08:00
|
|
|
CURLcode result;
|
|
|
|
char tmp[CURL_CHUNKED_MINLEN];
|
|
|
|
size_t nread;
|
|
|
|
bool eos;
|
|
|
|
|
|
|
|
DEBUGASSERT(!ctx->read_eos);
|
|
|
|
blen = CURLMIN(blen, CURL_CHUNKED_MAXLEN); /* respect our buffer pref */
|
|
|
|
if(blen < sizeof(tmp)) {
|
|
|
|
/* small read, make a chunk of decent size */
|
|
|
|
buf = tmp;
|
|
|
|
blen = sizeof(tmp);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* larger read, make a chunk that will fit when read back */
|
|
|
|
blen -= (8 + 2 + 2); /* deduct max overhead, 8 hex + 2*crlf */
|
|
|
|
}
|
|
|
|
|
|
|
|
result = Curl_creader_read(data, reader->next, buf, blen, &nread, &eos);
|
|
|
|
if(result)
|
|
|
|
return result;
|
|
|
|
if(eos)
|
|
|
|
ctx->read_eos = TRUE;
|
|
|
|
|
|
|
|
if(nread) {
|
|
|
|
/* actually got bytes, wrap them into the chunkbuf */
|
|
|
|
char hd[11] = "";
|
|
|
|
int hdlen;
|
|
|
|
size_t n;
|
|
|
|
|
|
|
|
hdlen = msnprintf(hd, sizeof(hd), "%zx\r\n", nread);
|
|
|
|
if(hdlen <= 0)
|
|
|
|
return CURLE_READ_ERROR;
|
|
|
|
/* On a soft-limited bufq, we do not need to check that all was written */
|
|
|
|
result = Curl_bufq_cwrite(&ctx->chunkbuf, hd, hdlen, &n);
|
|
|
|
if(!result)
|
|
|
|
result = Curl_bufq_cwrite(&ctx->chunkbuf, buf, nread, &n);
|
|
|
|
if(!result)
|
|
|
|
result = Curl_bufq_cwrite(&ctx->chunkbuf, "\r\n", 2, &n);
|
2024-03-28 21:12:54 +08:00
|
|
|
CURL_TRC_READ(data, "http_chunk, made chunk of %zu bytes -> %d",
|
|
|
|
nread, result);
|
2024-02-15 23:22:53 +08:00
|
|
|
if(result)
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
if(ctx->read_eos)
|
|
|
|
return add_last_chunk(data, reader);
|
|
|
|
return CURLE_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
static CURLcode cr_chunked_read(struct Curl_easy *data,
|
|
|
|
struct Curl_creader *reader,
|
|
|
|
char *buf, size_t blen,
|
|
|
|
size_t *pnread, bool *peos)
|
|
|
|
{
|
2024-03-06 16:52:43 +08:00
|
|
|
struct chunked_reader *ctx = reader->ctx;
|
2024-02-15 23:22:53 +08:00
|
|
|
CURLcode result = CURLE_READ_ERROR;
|
|
|
|
|
|
|
|
*pnread = 0;
|
|
|
|
*peos = ctx->eos;
|
|
|
|
|
|
|
|
if(!ctx->eos) {
|
|
|
|
if(!ctx->read_eos && Curl_bufq_is_empty(&ctx->chunkbuf)) {
|
|
|
|
/* Still getting data form the next reader, buffer is empty */
|
|
|
|
result = add_chunk(data, reader, buf, blen);
|
|
|
|
if(result)
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
if(!Curl_bufq_is_empty(&ctx->chunkbuf)) {
|
|
|
|
result = Curl_bufq_cread(&ctx->chunkbuf, buf, blen, pnread);
|
|
|
|
if(!result && ctx->read_eos && Curl_bufq_is_empty(&ctx->chunkbuf)) {
|
|
|
|
/* no more data, read all, done. */
|
|
|
|
ctx->eos = TRUE;
|
|
|
|
*peos = TRUE;
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* We may get here, because we are done or because callbacks paused */
|
|
|
|
DEBUGASSERT(ctx->eos || !ctx->read_eos);
|
|
|
|
return CURLE_OK;
|
|
|
|
}
|
|
|
|
|
2024-02-29 17:12:39 +08:00
|
|
|
static curl_off_t cr_chunked_total_length(struct Curl_easy *data,
|
|
|
|
struct Curl_creader *reader)
|
|
|
|
{
|
|
|
|
/* this reader changes length depending on input */
|
|
|
|
(void)data;
|
|
|
|
(void)reader;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2024-02-15 23:22:53 +08:00
|
|
|
/* HTTP chunked Transfer-Encoding encoder */
|
|
|
|
const struct Curl_crtype Curl_httpchunk_encoder = {
|
|
|
|
"chunked",
|
|
|
|
cr_chunked_init,
|
|
|
|
cr_chunked_read,
|
|
|
|
cr_chunked_close,
|
|
|
|
Curl_creader_def_needs_rewind,
|
2024-02-29 17:12:39 +08:00
|
|
|
cr_chunked_total_length,
|
|
|
|
Curl_creader_def_resume_from,
|
|
|
|
Curl_creader_def_rewind,
|
2024-02-29 17:12:39 +08:00
|
|
|
Curl_creader_def_unpause,
|
2024-03-12 00:23:15 +08:00
|
|
|
Curl_creader_def_done,
|
2024-02-15 23:22:53 +08:00
|
|
|
sizeof(struct chunked_reader)
|
|
|
|
};
|
|
|
|
|
|
|
|
CURLcode Curl_httpchunk_add_reader(struct Curl_easy *data)
|
|
|
|
{
|
|
|
|
struct Curl_creader *reader = NULL;
|
|
|
|
CURLcode result;
|
|
|
|
|
|
|
|
result = Curl_creader_create(&reader, data, &Curl_httpchunk_encoder,
|
|
|
|
CURL_CR_TRANSFER_ENCODE);
|
|
|
|
if(!result)
|
|
|
|
result = Curl_creader_add(data, reader);
|
|
|
|
|
|
|
|
if(result && reader)
|
|
|
|
Curl_creader_free(data, reader);
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2002-06-11 19:13:01 +08:00
|
|
|
#endif /* CURL_DISABLE_HTTP */
|