2010-01-21 21:58:30 +08:00
|
|
|
/***************************************************************************
|
|
|
|
|
* _ _ ____ _
|
|
|
|
|
* Project ___| | | | _ \| |
|
|
|
|
|
* / __| | | | |_) | |
|
|
|
|
|
* | (__| |_| | _ <| |___
|
|
|
|
|
* \___|\___/|_| \_\_____|
|
|
|
|
|
*
|
2023-01-02 20:51:48 +08:00
|
|
|
* Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
|
2010-01-21 21:58:30 +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.
|
2010-01-21 21:58:30 +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
|
|
|
|
|
* furnished to do so, under the terms of the COPYING file.
|
|
|
|
|
*
|
|
|
|
|
* This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY
|
|
|
|
|
* KIND, either express or implied.
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: curl
|
2022-05-17 17:16:50 +08:00
|
|
|
*
|
2010-01-21 21:58:30 +08:00
|
|
|
***************************************************************************/
|
|
|
|
|
|
2013-01-07 02:06:49 +08:00
|
|
|
#include "curl_setup.h"
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2020-12-14 21:10:33 +08:00
|
|
|
#if !defined(CURL_DISABLE_RTSP) && !defined(USE_HYPER)
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "urldata.h"
|
2010-01-21 21:58:30 +08:00
|
|
|
#include <curl/curl.h>
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "transfer.h"
|
|
|
|
|
#include "sendf.h"
|
|
|
|
|
#include "multiif.h"
|
|
|
|
|
#include "http.h"
|
|
|
|
|
#include "url.h"
|
|
|
|
|
#include "progress.h"
|
|
|
|
|
#include "rtsp.h"
|
2016-10-01 00:54:02 +08:00
|
|
|
#include "strcase.h"
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "select.h"
|
|
|
|
|
#include "connect.h"
|
2022-12-30 16:14:55 +08:00
|
|
|
#include "cfilters.h"
|
2016-11-07 17:55:25 +08:00
|
|
|
#include "strdup.h"
|
2016-04-29 21:46:40 +08:00
|
|
|
/* The last 3 #include files should be in this order */
|
2015-03-03 19:36:18 +08:00
|
|
|
#include "curl_printf.h"
|
2015-03-25 06:12:03 +08:00
|
|
|
#include "curl_memory.h"
|
2013-01-04 09:50:28 +08:00
|
|
|
#include "memdebug.h"
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2023-10-07 21:13:09 +08:00
|
|
|
#define RTP_PKT_LENGTH(p) ((((unsigned int)((unsigned char)((p)[2]))) << 8) | \
|
|
|
|
|
((unsigned int)((unsigned char)((p)[3]))))
|
2010-02-03 14:49:27 +08:00
|
|
|
|
2011-05-05 22:53:05 +08:00
|
|
|
/* protocol-specific functions set up to be called by the main engine */
|
2021-01-09 00:58:15 +08:00
|
|
|
static CURLcode rtsp_do(struct Curl_easy *data, bool *done);
|
|
|
|
|
static CURLcode rtsp_done(struct Curl_easy *data, CURLcode, bool premature);
|
|
|
|
|
static CURLcode rtsp_connect(struct Curl_easy *data, bool *done);
|
|
|
|
|
static CURLcode rtsp_disconnect(struct Curl_easy *data,
|
|
|
|
|
struct connectdata *conn, bool dead);
|
|
|
|
|
static int rtsp_getsock_do(struct Curl_easy *data,
|
|
|
|
|
struct connectdata *conn, curl_socket_t *socks);
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2011-05-05 22:27:03 +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
|
|
|
* Parse and write out an RTSP response.
|
2023-11-07 00:06:06 +08:00
|
|
|
* @param data the transfer
|
|
|
|
|
* @param conn the connection
|
|
|
|
|
* @param buf data read from connection
|
|
|
|
|
* @param blen amount of data in 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
|
|
|
* @param is_eos TRUE iff this is the last write
|
2023-11-07 00:06:06 +08:00
|
|
|
* @param readmore out, TRUE iff complete buf was consumed and more data
|
|
|
|
|
* is needed
|
2011-05-05 22:27:03 +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 CURLcode rtsp_rtp_write_resp(struct Curl_easy *data,
|
|
|
|
|
const char *buf,
|
|
|
|
|
size_t blen,
|
2024-03-11 19:35:07 +08:00
|
|
|
bool is_eos);
|
2011-05-05 22:27:03 +08:00
|
|
|
|
2021-01-09 00:58:15 +08:00
|
|
|
static CURLcode rtsp_setup_connection(struct Curl_easy *data,
|
|
|
|
|
struct connectdata *conn);
|
|
|
|
|
static unsigned int rtsp_conncheck(struct Curl_easy *data,
|
|
|
|
|
struct connectdata *check,
|
2017-05-31 19:09:56 +08:00
|
|
|
unsigned int checks_to_perform);
|
2011-05-05 22:27:03 +08:00
|
|
|
|
2010-01-21 21:58:30 +08:00
|
|
|
/* this returns the socket to wait for in the DO and DOING state for the multi
|
2024-07-01 22:47:21 +08:00
|
|
|
interface and then we are always _sending_ a request and thus we wait for
|
2010-01-21 21:58:30 +08:00
|
|
|
the single socket to become writable only */
|
2021-01-09 00:58:15 +08:00
|
|
|
static int rtsp_getsock_do(struct Curl_easy *data, struct connectdata *conn,
|
2019-07-30 17:02:03 +08:00
|
|
|
curl_socket_t *socks)
|
2010-01-21 21:58:30 +08:00
|
|
|
{
|
|
|
|
|
/* write mode */
|
2021-01-09 00:58:15 +08:00
|
|
|
(void)data;
|
2010-01-21 21:58:30 +08:00
|
|
|
socks[0] = conn->sock[FIRSTSOCKET];
|
|
|
|
|
return GETSOCK_WRITESOCK(0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static
|
2023-10-07 21:13:09 +08:00
|
|
|
CURLcode rtp_client_write(struct Curl_easy *data, const char *ptr, size_t len);
|
2023-03-21 15:45:59 +08:00
|
|
|
static
|
2024-03-21 19:15:59 +08:00
|
|
|
CURLcode rtsp_parse_transport(struct Curl_easy *data, const char *transport);
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* RTSP handler interface.
|
|
|
|
|
*/
|
|
|
|
|
const struct Curl_handler Curl_handler_rtsp = {
|
2024-05-07 22:55:23 +08:00
|
|
|
"rtsp", /* scheme */
|
2013-08-05 01:34:16 +08:00
|
|
|
rtsp_setup_connection, /* setup_connection */
|
2011-05-05 22:53:05 +08:00
|
|
|
rtsp_do, /* do_it */
|
|
|
|
|
rtsp_done, /* done */
|
2010-01-21 21:58:30 +08:00
|
|
|
ZERO_NULL, /* do_more */
|
2011-05-05 22:53:05 +08:00
|
|
|
rtsp_connect, /* connect_it */
|
2010-01-21 21:58:30 +08:00
|
|
|
ZERO_NULL, /* connecting */
|
|
|
|
|
ZERO_NULL, /* doing */
|
|
|
|
|
ZERO_NULL, /* proto_getsock */
|
|
|
|
|
rtsp_getsock_do, /* doing_getsock */
|
2011-10-22 05:36:54 +08:00
|
|
|
ZERO_NULL, /* domore_getsock */
|
2010-01-21 21:58:30 +08:00
|
|
|
ZERO_NULL, /* perform_getsock */
|
2011-05-05 22:53:05 +08:00
|
|
|
rtsp_disconnect, /* disconnect */
|
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
|
|
|
rtsp_rtp_write_resp, /* write_resp */
|
2024-03-21 19:15:59 +08:00
|
|
|
ZERO_NULL, /* write_resp_hd */
|
2017-05-31 19:09:56 +08:00
|
|
|
rtsp_conncheck, /* connection_check */
|
2021-05-17 14:54:00 +08:00
|
|
|
ZERO_NULL, /* attach connection */
|
2010-01-21 21:58:30 +08:00
|
|
|
PORT_RTSP, /* defport */
|
2011-03-15 05:52:14 +08:00
|
|
|
CURLPROTO_RTSP, /* protocol */
|
2020-09-21 19:45:24 +08:00
|
|
|
CURLPROTO_RTSP, /* family */
|
2011-03-15 05:22:22 +08:00
|
|
|
PROTOPT_NONE /* flags */
|
2010-01-21 21:58:30 +08:00
|
|
|
};
|
|
|
|
|
|
2023-04-04 20:44:25 +08:00
|
|
|
#define MAX_RTP_BUFFERSIZE 1000000 /* arbitrary */
|
2013-08-05 01:34:16 +08:00
|
|
|
|
2021-01-09 00:58:15 +08:00
|
|
|
static CURLcode rtsp_setup_connection(struct Curl_easy *data,
|
|
|
|
|
struct connectdata *conn)
|
2013-08-05 01:34:16 +08:00
|
|
|
{
|
|
|
|
|
struct RTSP *rtsp;
|
2021-01-09 00:58:15 +08:00
|
|
|
(void)conn;
|
2013-08-05 01:34:16 +08:00
|
|
|
|
2021-01-09 00:58:15 +08:00
|
|
|
data->req.p.rtsp = rtsp = calloc(1, sizeof(struct RTSP));
|
2013-08-05 01:34:16 +08:00
|
|
|
if(!rtsp)
|
|
|
|
|
return CURLE_OUT_OF_MEMORY;
|
|
|
|
|
|
2023-04-04 20:44:25 +08:00
|
|
|
Curl_dyn_init(&conn->proto.rtspc.buf, MAX_RTP_BUFFERSIZE);
|
2013-08-05 01:34:16 +08:00
|
|
|
return CURLE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-05-31 19:09:56 +08:00
|
|
|
/*
|
|
|
|
|
* Function to check on various aspects of a connection.
|
|
|
|
|
*/
|
2021-01-09 00:58:15 +08:00
|
|
|
static unsigned int rtsp_conncheck(struct Curl_easy *data,
|
|
|
|
|
struct connectdata *conn,
|
2017-05-31 19:09:56 +08:00
|
|
|
unsigned int checks_to_perform)
|
|
|
|
|
{
|
|
|
|
|
unsigned int ret_val = CONNRESULT_NONE;
|
2021-01-09 00:58:15 +08:00
|
|
|
(void)data;
|
2017-05-31 19:09:56 +08:00
|
|
|
|
|
|
|
|
if(checks_to_perform & CONNCHECK_ISDEAD) {
|
2023-03-06 19:44:45 +08:00
|
|
|
bool input_pending;
|
|
|
|
|
if(!Curl_conn_is_alive(data, conn, &input_pending))
|
2017-05-31 19:09:56 +08:00
|
|
|
ret_val |= CONNRESULT_DEAD;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret_val;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-01-09 00:58:15 +08:00
|
|
|
static CURLcode rtsp_connect(struct Curl_easy *data, bool *done)
|
2010-01-21 21:58:30 +08:00
|
|
|
{
|
|
|
|
|
CURLcode httpStatus;
|
|
|
|
|
|
2021-01-09 00:58:15 +08:00
|
|
|
httpStatus = Curl_http_connect(data, done);
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
/* Initialize the CSeq if not already done */
|
|
|
|
|
if(data->state.rtsp_next_client_CSeq == 0)
|
|
|
|
|
data->state.rtsp_next_client_CSeq = 1;
|
|
|
|
|
if(data->state.rtsp_next_server_CSeq == 0)
|
|
|
|
|
data->state.rtsp_next_server_CSeq = 1;
|
|
|
|
|
|
2021-01-09 00:58:15 +08:00
|
|
|
data->conn->proto.rtspc.rtp_channel = -1;
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
return httpStatus;
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-09 00:58:15 +08:00
|
|
|
static CURLcode rtsp_disconnect(struct Curl_easy *data,
|
|
|
|
|
struct connectdata *conn, bool dead)
|
2010-11-19 20:43:20 +08:00
|
|
|
{
|
2011-05-05 22:53:05 +08:00
|
|
|
(void) dead;
|
2021-01-09 00:58:15 +08:00
|
|
|
(void) data;
|
2023-04-04 20:44:25 +08:00
|
|
|
Curl_dyn_free(&conn->proto.rtspc.buf);
|
2010-01-21 21:58:30 +08:00
|
|
|
return CURLE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-01-09 00:58:15 +08:00
|
|
|
static CURLcode rtsp_done(struct Curl_easy *data,
|
2011-05-05 22:53:05 +08:00
|
|
|
CURLcode status, bool premature)
|
2010-01-21 21:58:30 +08:00
|
|
|
{
|
2020-11-23 15:32:41 +08:00
|
|
|
struct RTSP *rtsp = data->req.p.rtsp;
|
2010-02-06 21:21:45 +08:00
|
|
|
CURLcode httpStatus;
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2010-01-28 09:39:16 +08:00
|
|
|
/* Bypass HTTP empty-reply checks on receive */
|
|
|
|
|
if(data->set.rtspreq == RTSPREQ_RECEIVE)
|
|
|
|
|
premature = TRUE;
|
|
|
|
|
|
2021-01-09 00:58:15 +08:00
|
|
|
httpStatus = Curl_http_done(data, status, premature);
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2022-03-01 03:28:37 +08:00
|
|
|
if(rtsp && !status && !httpStatus) {
|
2010-02-06 21:21:45 +08:00
|
|
|
/* Check the sequence numbers */
|
2018-06-03 04:52:56 +08:00
|
|
|
long CSeq_sent = rtsp->CSeq_sent;
|
|
|
|
|
long CSeq_recv = rtsp->CSeq_recv;
|
2010-02-06 21:21:45 +08:00
|
|
|
if((data->set.rtspreq != RTSPREQ_RECEIVE) && (CSeq_sent != CSeq_recv)) {
|
2011-04-20 21:17:42 +08:00
|
|
|
failf(data,
|
|
|
|
|
"The CSeq of this request %ld did not match the response %ld",
|
2010-02-06 21:21:45 +08:00
|
|
|
CSeq_sent, CSeq_recv);
|
|
|
|
|
return CURLE_RTSP_CSEQ_ERROR;
|
|
|
|
|
}
|
2017-03-10 21:28:37 +08:00
|
|
|
if(data->set.rtspreq == RTSPREQ_RECEIVE &&
|
2023-04-04 20:44:25 +08:00
|
|
|
(data->conn->proto.rtspc.rtp_channel == -1)) {
|
2021-07-06 23:05:17 +08:00
|
|
|
infof(data, "Got an RTP Receive with a CSeq of %ld", CSeq_recv);
|
2010-02-06 21:21:45 +08:00
|
|
|
}
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return httpStatus;
|
|
|
|
|
}
|
|
|
|
|
|
2021-01-09 00:58:15 +08:00
|
|
|
static CURLcode rtsp_do(struct Curl_easy *data, bool *done)
|
2010-01-21 21:58:30 +08:00
|
|
|
{
|
2021-01-09 00:58:15 +08:00
|
|
|
struct connectdata *conn = data->conn;
|
2017-09-10 05:09:06 +08:00
|
|
|
CURLcode result = CURLE_OK;
|
2010-01-21 21:58:30 +08:00
|
|
|
Curl_RtspReq rtspreq = data->set.rtspreq;
|
2020-11-23 15:32:41 +08:00
|
|
|
struct RTSP *rtsp = data->req.p.rtsp;
|
2020-05-02 23:04:08 +08:00
|
|
|
struct dynbuf req_buffer;
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
const char *p_request = NULL;
|
|
|
|
|
const char *p_session_id = NULL;
|
|
|
|
|
const char *p_accept = NULL;
|
|
|
|
|
const char *p_accept_encoding = NULL;
|
|
|
|
|
const char *p_range = NULL;
|
|
|
|
|
const char *p_referrer = NULL;
|
|
|
|
|
const char *p_stream_uri = NULL;
|
|
|
|
|
const char *p_transport = NULL;
|
|
|
|
|
const char *p_uagent = NULL;
|
2015-08-21 05:02:28 +08:00
|
|
|
const char *p_proxyuserpwd = NULL;
|
|
|
|
|
const char *p_userpwd = NULL;
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
*done = TRUE;
|
2024-02-15 23:22:53 +08:00
|
|
|
/* Initialize a dynamic send buffer */
|
|
|
|
|
Curl_dyn_init(&req_buffer, DYN_RTSP_REQ_HEADER);
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
rtsp->CSeq_sent = data->state.rtsp_next_client_CSeq;
|
|
|
|
|
rtsp->CSeq_recv = 0;
|
|
|
|
|
|
2022-11-08 22:34:12 +08:00
|
|
|
/* Setup the first_* fields to allow auth details get sent
|
|
|
|
|
to this origin */
|
|
|
|
|
|
2022-11-10 15:38:01 +08:00
|
|
|
if(!data->state.first_host) {
|
|
|
|
|
data->state.first_host = strdup(conn->host.name);
|
|
|
|
|
if(!data->state.first_host)
|
|
|
|
|
return CURLE_OUT_OF_MEMORY;
|
2022-11-08 22:34:12 +08:00
|
|
|
|
2022-11-10 15:38:01 +08:00
|
|
|
data->state.first_remote_port = conn->remote_port;
|
|
|
|
|
data->state.first_remote_protocol = conn->handler->protocol;
|
|
|
|
|
}
|
2022-11-08 22:34:12 +08:00
|
|
|
|
2010-01-21 21:58:30 +08:00
|
|
|
/* Setup the 'p_request' pointer to the proper p_request string
|
|
|
|
|
* Since all RTSP requests are included here, there is no need to
|
|
|
|
|
* support custom requests like HTTP.
|
|
|
|
|
**/
|
2024-07-01 22:47:21 +08:00
|
|
|
data->req.no_body = TRUE; /* most requests do not contain a body */
|
2010-01-21 21:58:30 +08:00
|
|
|
switch(rtspreq) {
|
2015-05-22 22:32:42 +08:00
|
|
|
default:
|
|
|
|
|
failf(data, "Got invalid RTSP request");
|
2010-01-21 21:58:30 +08:00
|
|
|
return CURLE_BAD_FUNCTION_ARGUMENT;
|
|
|
|
|
case RTSPREQ_OPTIONS:
|
|
|
|
|
p_request = "OPTIONS";
|
|
|
|
|
break;
|
|
|
|
|
case RTSPREQ_DESCRIBE:
|
|
|
|
|
p_request = "DESCRIBE";
|
2022-11-11 17:57:04 +08:00
|
|
|
data->req.no_body = FALSE;
|
2010-01-21 21:58:30 +08:00
|
|
|
break;
|
|
|
|
|
case RTSPREQ_ANNOUNCE:
|
|
|
|
|
p_request = "ANNOUNCE";
|
|
|
|
|
break;
|
|
|
|
|
case RTSPREQ_SETUP:
|
|
|
|
|
p_request = "SETUP";
|
|
|
|
|
break;
|
|
|
|
|
case RTSPREQ_PLAY:
|
|
|
|
|
p_request = "PLAY";
|
|
|
|
|
break;
|
|
|
|
|
case RTSPREQ_PAUSE:
|
|
|
|
|
p_request = "PAUSE";
|
|
|
|
|
break;
|
|
|
|
|
case RTSPREQ_TEARDOWN:
|
|
|
|
|
p_request = "TEARDOWN";
|
|
|
|
|
break;
|
|
|
|
|
case RTSPREQ_GET_PARAMETER:
|
2010-03-24 13:35:03 +08:00
|
|
|
/* GET_PARAMETER's no_body status is determined later */
|
2010-01-21 21:58:30 +08:00
|
|
|
p_request = "GET_PARAMETER";
|
2022-11-11 17:57:04 +08:00
|
|
|
data->req.no_body = FALSE;
|
2010-01-21 21:58:30 +08:00
|
|
|
break;
|
|
|
|
|
case RTSPREQ_SET_PARAMETER:
|
|
|
|
|
p_request = "SET_PARAMETER";
|
|
|
|
|
break;
|
|
|
|
|
case RTSPREQ_RECORD:
|
|
|
|
|
p_request = "RECORD";
|
|
|
|
|
break;
|
|
|
|
|
case RTSPREQ_RECEIVE:
|
|
|
|
|
p_request = "";
|
2022-10-31 00:38:16 +08:00
|
|
|
/* Treat interleaved RTP as body */
|
2022-11-11 17:57:04 +08:00
|
|
|
data->req.no_body = FALSE;
|
2010-01-21 21:58:30 +08:00
|
|
|
break;
|
|
|
|
|
case RTSPREQ_LAST:
|
|
|
|
|
failf(data, "Got invalid RTSP request: RTSPREQ_LAST");
|
|
|
|
|
return CURLE_BAD_FUNCTION_ARGUMENT;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(rtspreq == RTSPREQ_RECEIVE) {
|
2024-06-10 19:32:13 +08:00
|
|
|
Curl_xfer_setup1(data, CURL_XFER_RECV, -1, TRUE);
|
2024-02-15 23:22:53 +08:00
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
p_session_id = data->set.str[STRING_RTSP_SESSION_ID];
|
|
|
|
|
if(!p_session_id &&
|
2024-06-03 04:30:52 +08:00
|
|
|
(rtspreq & ~(Curl_RtspReq)(RTSPREQ_OPTIONS |
|
|
|
|
|
RTSPREQ_DESCRIBE |
|
|
|
|
|
RTSPREQ_SETUP))) {
|
2010-01-21 21:58:30 +08:00
|
|
|
failf(data, "Refusing to issue an RTSP request [%s] without a session ID.",
|
2015-06-15 15:05:07 +08:00
|
|
|
p_request);
|
2024-02-15 23:22:53 +08:00
|
|
|
result = CURLE_BAD_FUNCTION_ARGUMENT;
|
|
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Stream URI. Default to server '*' if not specified */
|
|
|
|
|
if(data->set.str[STRING_RTSP_STREAM_URI]) {
|
|
|
|
|
p_stream_uri = data->set.str[STRING_RTSP_STREAM_URI];
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
p_stream_uri = "*";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Transport Header for SETUP requests */
|
2022-02-09 07:57:00 +08:00
|
|
|
p_transport = Curl_checkheaders(data, STRCONST("Transport"));
|
2010-01-21 21:58:30 +08:00
|
|
|
if(rtspreq == RTSPREQ_SETUP && !p_transport) {
|
|
|
|
|
/* New Transport: setting? */
|
|
|
|
|
if(data->set.str[STRING_RTSP_TRANSPORT]) {
|
2020-06-15 17:28:17 +08:00
|
|
|
Curl_safefree(data->state.aptr.rtsp_transport);
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2020-06-15 17:28:17 +08:00
|
|
|
data->state.aptr.rtsp_transport =
|
2010-01-21 21:58:30 +08:00
|
|
|
aprintf("Transport: %s\r\n",
|
|
|
|
|
data->set.str[STRING_RTSP_TRANSPORT]);
|
2020-06-15 17:28:17 +08:00
|
|
|
if(!data->state.aptr.rtsp_transport)
|
2010-01-21 21:58:30 +08:00
|
|
|
return CURLE_OUT_OF_MEMORY;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
failf(data,
|
|
|
|
|
"Refusing to issue an RTSP SETUP without a Transport: header.");
|
2024-02-15 23:22:53 +08:00
|
|
|
result = CURLE_BAD_FUNCTION_ARGUMENT;
|
|
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
2020-06-15 17:28:17 +08:00
|
|
|
p_transport = data->state.aptr.rtsp_transport;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Accept Headers for DESCRIBE requests */
|
|
|
|
|
if(rtspreq == RTSPREQ_DESCRIBE) {
|
|
|
|
|
/* Accept Header */
|
2022-02-09 07:57:00 +08:00
|
|
|
p_accept = Curl_checkheaders(data, STRCONST("Accept"))?
|
2010-01-21 21:58:30 +08:00
|
|
|
NULL:"Accept: application/sdp\r\n";
|
|
|
|
|
|
|
|
|
|
/* Accept-Encoding header */
|
2022-02-09 07:57:00 +08:00
|
|
|
if(!Curl_checkheaders(data, STRCONST("Accept-Encoding")) &&
|
2010-01-21 21:58:30 +08:00
|
|
|
data->set.str[STRING_ENCODING]) {
|
2020-06-15 17:28:17 +08:00
|
|
|
Curl_safefree(data->state.aptr.accept_encoding);
|
|
|
|
|
data->state.aptr.accept_encoding =
|
2010-01-21 21:58:30 +08:00
|
|
|
aprintf("Accept-Encoding: %s\r\n", data->set.str[STRING_ENCODING]);
|
|
|
|
|
|
2024-02-15 23:22:53 +08:00
|
|
|
if(!data->state.aptr.accept_encoding) {
|
|
|
|
|
result = CURLE_OUT_OF_MEMORY;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
2020-06-15 17:28:17 +08:00
|
|
|
p_accept_encoding = data->state.aptr.accept_encoding;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-01-04 09:50:28 +08:00
|
|
|
/* The User-Agent string might have been allocated in url.c already, because
|
|
|
|
|
it might have been used in the proxy connect, but if we have got a header
|
|
|
|
|
with the user-agent string specified, we erase the previously made string
|
|
|
|
|
here. */
|
2022-02-09 07:57:00 +08:00
|
|
|
if(Curl_checkheaders(data, STRCONST("User-Agent")) &&
|
|
|
|
|
data->state.aptr.uagent) {
|
2020-06-15 17:28:17 +08:00
|
|
|
Curl_safefree(data->state.aptr.uagent);
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
2022-02-09 07:57:00 +08:00
|
|
|
else if(!Curl_checkheaders(data, STRCONST("User-Agent")) &&
|
2010-01-21 21:58:30 +08:00
|
|
|
data->set.str[STRING_USERAGENT]) {
|
2020-06-15 17:28:17 +08:00
|
|
|
p_uagent = data->state.aptr.uagent;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
2015-08-21 05:02:28 +08:00
|
|
|
/* setup the authentication headers */
|
2021-01-09 00:58:15 +08:00
|
|
|
result = Curl_http_output_auth(data, conn, p_request, HTTPREQ_GET,
|
2021-01-08 23:17:12 +08:00
|
|
|
p_stream_uri, FALSE);
|
2015-08-21 05:02:28 +08:00
|
|
|
if(result)
|
2024-02-15 23:22:53 +08:00
|
|
|
goto out;
|
2015-08-21 05:02:28 +08:00
|
|
|
|
2024-03-26 07:19:23 +08:00
|
|
|
#ifndef CURL_DISABLE_PROXY
|
2020-06-15 17:28:17 +08:00
|
|
|
p_proxyuserpwd = data->state.aptr.proxyuserpwd;
|
2024-03-26 07:19:23 +08:00
|
|
|
#endif
|
2020-06-15 17:28:17 +08:00
|
|
|
p_userpwd = data->state.aptr.userpwd;
|
2015-08-21 05:02:28 +08:00
|
|
|
|
2010-01-21 21:58:30 +08:00
|
|
|
/* Referrer */
|
2020-06-15 17:28:17 +08:00
|
|
|
Curl_safefree(data->state.aptr.ref);
|
2022-02-09 07:57:00 +08:00
|
|
|
if(data->state.referer && !Curl_checkheaders(data, STRCONST("Referer")))
|
2021-03-26 21:25:45 +08:00
|
|
|
data->state.aptr.ref = aprintf("Referer: %s\r\n", data->state.referer);
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2020-06-15 17:28:17 +08:00
|
|
|
p_referrer = data->state.aptr.ref;
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Range Header
|
|
|
|
|
* Only applies to PLAY, PAUSE, RECORD
|
|
|
|
|
*
|
|
|
|
|
* Go ahead and use the Range stuff supplied for HTTP
|
|
|
|
|
*/
|
|
|
|
|
if(data->state.use_range &&
|
|
|
|
|
(rtspreq & (RTSPREQ_PLAY | RTSPREQ_PAUSE | RTSPREQ_RECORD))) {
|
|
|
|
|
|
|
|
|
|
/* Check to see if there is a range set in the custom headers */
|
2022-02-09 07:57:00 +08:00
|
|
|
if(!Curl_checkheaders(data, STRCONST("Range")) && data->state.range) {
|
2020-06-15 17:28:17 +08:00
|
|
|
Curl_safefree(data->state.aptr.rangeline);
|
|
|
|
|
data->state.aptr.rangeline = aprintf("Range: %s\r\n", data->state.range);
|
|
|
|
|
p_range = data->state.aptr.rangeline;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Sanity check the custom headers
|
|
|
|
|
*/
|
2022-02-09 07:57:00 +08:00
|
|
|
if(Curl_checkheaders(data, STRCONST("CSeq"))) {
|
2010-01-21 21:58:30 +08:00
|
|
|
failf(data, "CSeq cannot be set as a custom header.");
|
2024-02-15 23:22:53 +08:00
|
|
|
result = CURLE_RTSP_CSEQ_ERROR;
|
|
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
2022-02-09 07:57:00 +08:00
|
|
|
if(Curl_checkheaders(data, STRCONST("Session"))) {
|
2010-01-21 21:58:30 +08:00
|
|
|
failf(data, "Session ID cannot be set as a custom header.");
|
2024-02-15 23:22:53 +08:00
|
|
|
result = CURLE_BAD_FUNCTION_ARGUMENT;
|
|
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
result =
|
2020-05-02 23:04:08 +08:00
|
|
|
Curl_dyn_addf(&req_buffer,
|
|
|
|
|
"%s %s RTSP/1.0\r\n" /* Request Stream-URI RTSP/1.0 */
|
|
|
|
|
"CSeq: %ld\r\n", /* CSeq */
|
|
|
|
|
p_request, p_stream_uri, rtsp->CSeq_sent);
|
2010-01-21 21:58:30 +08:00
|
|
|
if(result)
|
2024-02-15 23:22:53 +08:00
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Rather than do a normal alloc line, keep the session_id unformatted
|
|
|
|
|
* to make comparison easier
|
|
|
|
|
*/
|
|
|
|
|
if(p_session_id) {
|
2020-05-02 23:04:08 +08:00
|
|
|
result = Curl_dyn_addf(&req_buffer, "Session: %s\r\n", p_session_id);
|
2010-01-21 21:58:30 +08:00
|
|
|
if(result)
|
2024-02-15 23:22:53 +08:00
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Shared HTTP-like options
|
|
|
|
|
*/
|
2020-05-02 23:04:08 +08:00
|
|
|
result = Curl_dyn_addf(&req_buffer,
|
|
|
|
|
"%s" /* transport */
|
|
|
|
|
"%s" /* accept */
|
|
|
|
|
"%s" /* accept-encoding */
|
|
|
|
|
"%s" /* range */
|
|
|
|
|
"%s" /* referrer */
|
|
|
|
|
"%s" /* user-agent */
|
|
|
|
|
"%s" /* proxyuserpwd */
|
|
|
|
|
"%s" /* userpwd */
|
|
|
|
|
,
|
|
|
|
|
p_transport ? p_transport : "",
|
|
|
|
|
p_accept ? p_accept : "",
|
|
|
|
|
p_accept_encoding ? p_accept_encoding : "",
|
|
|
|
|
p_range ? p_range : "",
|
|
|
|
|
p_referrer ? p_referrer : "",
|
|
|
|
|
p_uagent ? p_uagent : "",
|
|
|
|
|
p_proxyuserpwd ? p_proxyuserpwd : "",
|
|
|
|
|
p_userpwd ? p_userpwd : "");
|
2015-08-21 05:02:28 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Free userpwd now --- cannot reuse this for Negotiate and possibly NTLM
|
|
|
|
|
* with basic and digest, it will be freed anyway by the next request
|
|
|
|
|
*/
|
2020-06-15 17:28:17 +08:00
|
|
|
Curl_safefree(data->state.aptr.userpwd);
|
2015-08-21 05:02:28 +08:00
|
|
|
|
2010-02-06 21:21:45 +08:00
|
|
|
if(result)
|
2024-02-15 23:22:53 +08:00
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
if((rtspreq == RTSPREQ_SETUP) || (rtspreq == RTSPREQ_DESCRIBE)) {
|
2021-01-09 00:58:15 +08:00
|
|
|
result = Curl_add_timecondition(data, &req_buffer);
|
2010-01-21 21:58:30 +08:00
|
|
|
if(result)
|
2024-02-15 23:22:53 +08:00
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
2021-01-09 00:58:15 +08:00
|
|
|
result = Curl_add_custom_headers(data, FALSE, &req_buffer);
|
2010-01-21 21:58:30 +08:00
|
|
|
if(result)
|
2024-02-15 23:22:53 +08:00
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2010-03-24 13:35:03 +08:00
|
|
|
if(rtspreq == RTSPREQ_ANNOUNCE ||
|
|
|
|
|
rtspreq == RTSPREQ_SET_PARAMETER ||
|
|
|
|
|
rtspreq == RTSPREQ_GET_PARAMETER) {
|
2024-02-29 17:12:39 +08:00
|
|
|
curl_off_t req_clen; /* request content length */
|
2010-03-24 13:35:03 +08:00
|
|
|
|
2023-04-25 14:28:01 +08:00
|
|
|
if(data->state.upload) {
|
2024-02-29 17:12:39 +08:00
|
|
|
req_clen = data->state.infilesize;
|
2020-06-02 04:58:46 +08:00
|
|
|
data->state.httpreq = HTTPREQ_PUT;
|
2024-02-29 17:12:39 +08:00
|
|
|
result = Curl_creader_set_fread(data, req_clen);
|
2024-02-15 23:22:53 +08:00
|
|
|
if(result)
|
|
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
else {
|
2024-02-29 17:12:39 +08:00
|
|
|
if(data->set.postfields) {
|
|
|
|
|
size_t plen = strlen(data->set.postfields);
|
|
|
|
|
req_clen = (curl_off_t)plen;
|
|
|
|
|
result = Curl_creader_set_buf(data, data->set.postfields, plen);
|
|
|
|
|
}
|
|
|
|
|
else if(data->state.infilesize >= 0) {
|
|
|
|
|
req_clen = data->state.infilesize;
|
|
|
|
|
result = Curl_creader_set_fread(data, req_clen);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
req_clen = 0;
|
|
|
|
|
result = Curl_creader_set_null(data);
|
|
|
|
|
}
|
2024-02-15 23:22:53 +08:00
|
|
|
if(result)
|
|
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
2024-02-29 17:12:39 +08:00
|
|
|
if(req_clen > 0) {
|
2010-03-24 13:35:03 +08:00
|
|
|
/* As stated in the http comments, it is probably not wise to
|
|
|
|
|
* actually set a custom Content-Length in the headers */
|
2022-02-09 07:57:00 +08:00
|
|
|
if(!Curl_checkheaders(data, STRCONST("Content-Length"))) {
|
2018-09-14 17:48:53 +08:00
|
|
|
result =
|
2020-05-02 23:04:08 +08:00
|
|
|
Curl_dyn_addf(&req_buffer,
|
|
|
|
|
"Content-Length: %" CURL_FORMAT_CURL_OFF_T"\r\n",
|
2024-02-29 17:12:39 +08:00
|
|
|
req_clen);
|
2010-02-07 01:30:06 +08:00
|
|
|
if(result)
|
2024-02-15 23:22:53 +08:00
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
2010-03-24 13:35:03 +08:00
|
|
|
if(rtspreq == RTSPREQ_SET_PARAMETER ||
|
|
|
|
|
rtspreq == RTSPREQ_GET_PARAMETER) {
|
2022-02-09 07:57:00 +08:00
|
|
|
if(!Curl_checkheaders(data, STRCONST("Content-Type"))) {
|
2022-02-08 02:25:09 +08:00
|
|
|
result = Curl_dyn_addn(&req_buffer,
|
|
|
|
|
STRCONST("Content-Type: "
|
|
|
|
|
"text/parameters\r\n"));
|
2010-03-24 13:35:03 +08:00
|
|
|
if(result)
|
2024-02-15 23:22:53 +08:00
|
|
|
goto out;
|
2010-03-24 13:35:03 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(rtspreq == RTSPREQ_ANNOUNCE) {
|
2022-02-09 07:57:00 +08:00
|
|
|
if(!Curl_checkheaders(data, STRCONST("Content-Type"))) {
|
2022-02-08 02:25:09 +08:00
|
|
|
result = Curl_dyn_addn(&req_buffer,
|
|
|
|
|
STRCONST("Content-Type: "
|
|
|
|
|
"application/sdp\r\n"));
|
2010-03-24 13:35:03 +08:00
|
|
|
if(result)
|
2024-02-15 23:22:53 +08:00
|
|
|
goto out;
|
2010-03-24 13:35:03 +08:00
|
|
|
}
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
2011-04-20 21:17:42 +08:00
|
|
|
}
|
|
|
|
|
else if(rtspreq == RTSPREQ_GET_PARAMETER) {
|
2010-03-24 13:35:03 +08:00
|
|
|
/* Check for an empty GET_PARAMETER (heartbeat) request */
|
2020-06-02 04:58:46 +08:00
|
|
|
data->state.httpreq = HTTPREQ_HEAD;
|
2022-11-11 17:57:04 +08:00
|
|
|
data->req.no_body = TRUE;
|
2010-03-24 13:35:03 +08:00
|
|
|
}
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
2024-02-15 23:22:53 +08:00
|
|
|
else {
|
2024-02-29 17:12:39 +08:00
|
|
|
result = Curl_creader_set_null(data);
|
2024-02-15 23:22:53 +08:00
|
|
|
if(result)
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
/* Finish the request buffer */
|
2022-02-08 02:25:09 +08:00
|
|
|
result = Curl_dyn_addn(&req_buffer, STRCONST("\r\n"));
|
2010-01-21 21:58:30 +08:00
|
|
|
if(result)
|
2024-02-15 23:22:53 +08:00
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2024-06-10 19:32:13 +08:00
|
|
|
Curl_xfer_setup1(data, CURL_XFER_SENDRECV, -1, TRUE);
|
2024-02-28 21:51:53 +08:00
|
|
|
|
2010-01-21 21:58:30 +08:00
|
|
|
/* issue the request */
|
2024-02-15 23:22:53 +08:00
|
|
|
result = Curl_req_send(data, &req_buffer);
|
2010-01-21 21:58:30 +08:00
|
|
|
if(result) {
|
|
|
|
|
failf(data, "Failed sending RTSP request");
|
2024-02-15 23:22:53 +08:00
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Increment the CSeq on success */
|
|
|
|
|
data->state.rtsp_next_client_CSeq++;
|
|
|
|
|
|
2019-02-28 18:36:26 +08:00
|
|
|
if(data->req.writebytecount) {
|
2010-01-21 21:58:30 +08:00
|
|
|
/* if a request-body has been sent off, we make sure this progress is
|
|
|
|
|
noted properly */
|
2019-02-28 18:36:26 +08:00
|
|
|
Curl_pgrsSetUploadCounter(data, data->req.writebytecount);
|
2021-01-18 18:56:50 +08:00
|
|
|
if(Curl_pgrsUpdate(data))
|
2010-01-21 21:58:30 +08:00
|
|
|
result = CURLE_ABORTED_BY_CALLBACK;
|
|
|
|
|
}
|
2024-02-15 23:22:53 +08:00
|
|
|
out:
|
|
|
|
|
Curl_dyn_free(&req_buffer);
|
2010-01-21 21:58:30 +08:00
|
|
|
return 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
|
|
|
/**
|
|
|
|
|
* write any BODY bytes missing to the client, ignore the rest.
|
|
|
|
|
*/
|
|
|
|
|
static CURLcode rtp_write_body_junk(struct Curl_easy *data,
|
|
|
|
|
const char *buf,
|
|
|
|
|
size_t blen)
|
|
|
|
|
{
|
|
|
|
|
struct rtsp_conn *rtspc = &(data->conn->proto.rtspc);
|
|
|
|
|
curl_off_t body_remain;
|
|
|
|
|
bool in_body;
|
|
|
|
|
|
|
|
|
|
in_body = (data->req.headerline && !rtspc->in_header) &&
|
|
|
|
|
(data->req.size >= 0) &&
|
|
|
|
|
(data->req.bytecount < data->req.size);
|
|
|
|
|
body_remain = in_body? (data->req.size - data->req.bytecount) : 0;
|
|
|
|
|
DEBUGASSERT(body_remain >= 0);
|
|
|
|
|
if(body_remain) {
|
|
|
|
|
if((curl_off_t)blen > body_remain)
|
|
|
|
|
blen = (size_t)body_remain;
|
|
|
|
|
return Curl_client_write(data, CLIENTWRITE_BODY, (char *)buf, blen);
|
|
|
|
|
}
|
|
|
|
|
return CURLE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-07 21:13:09 +08:00
|
|
|
static CURLcode rtsp_filter_rtp(struct Curl_easy *data,
|
|
|
|
|
const char *buf,
|
|
|
|
|
size_t blen,
|
|
|
|
|
size_t *pconsumed)
|
|
|
|
|
{
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
struct rtsp_conn *rtspc = &(data->conn->proto.rtspc);
|
2023-10-07 21:13:09 +08:00
|
|
|
CURLcode result = CURLE_OK;
|
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
|
|
|
size_t skip_len = 0;
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2023-10-07 21:13:09 +08:00
|
|
|
*pconsumed = 0;
|
|
|
|
|
while(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
|
|
|
bool in_body = (data->req.headerline && !rtspc->in_header) &&
|
|
|
|
|
(data->req.size >= 0) &&
|
|
|
|
|
(data->req.bytecount < data->req.size);
|
2023-10-07 21:13:09 +08:00
|
|
|
switch(rtspc->state) {
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2023-10-07 21:13:09 +08:00
|
|
|
case RTP_PARSE_SKIP: {
|
|
|
|
|
DEBUGASSERT(Curl_dyn_len(&rtspc->buf) == 0);
|
|
|
|
|
while(blen && buf[0] != '$') {
|
|
|
|
|
if(!in_body && buf[0] == 'R' &&
|
|
|
|
|
data->set.rtspreq != RTSPREQ_RECEIVE) {
|
|
|
|
|
if(strncmp(buf, "RTSP/", (blen < 5) ? blen : 5) == 0) {
|
|
|
|
|
/* This could be the next response, no consume and return */
|
|
|
|
|
if(*pconsumed) {
|
|
|
|
|
DEBUGF(infof(data, "RTP rtsp_filter_rtp[SKIP] RTSP/ prefix, "
|
|
|
|
|
"skipping %zd bytes of junk", *pconsumed));
|
|
|
|
|
}
|
|
|
|
|
rtspc->state = RTP_PARSE_SKIP;
|
|
|
|
|
rtspc->in_header = TRUE;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
2023-03-21 15:45:59 +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
|
|
|
/* junk/BODY, consume without buffering */
|
2023-10-07 21:13:09 +08:00
|
|
|
*pconsumed += 1;
|
|
|
|
|
++buf;
|
|
|
|
|
--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
|
|
|
++skip_len;
|
2023-10-07 21:13:09 +08:00
|
|
|
}
|
|
|
|
|
if(blen && buf[0] == '$') {
|
|
|
|
|
/* possible start of an RTP message, buffer */
|
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(skip_len) {
|
|
|
|
|
/* end of junk/BODY bytes, flush */
|
|
|
|
|
result = rtp_write_body_junk(data,
|
|
|
|
|
(char *)(buf - skip_len), skip_len);
|
|
|
|
|
skip_len = 0;
|
|
|
|
|
if(result)
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
2023-10-07 21:13:09 +08:00
|
|
|
if(Curl_dyn_addn(&rtspc->buf, buf, 1)) {
|
|
|
|
|
result = CURLE_OUT_OF_MEMORY;
|
|
|
|
|
goto out;
|
2023-03-21 15:45:59 +08:00
|
|
|
}
|
2023-10-07 21:13:09 +08:00
|
|
|
*pconsumed += 1;
|
|
|
|
|
++buf;
|
|
|
|
|
--blen;
|
|
|
|
|
rtspc->state = RTP_PARSE_CHANNEL;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2023-10-07 21:13:09 +08:00
|
|
|
case RTP_PARSE_CHANNEL: {
|
|
|
|
|
int idx = ((unsigned char)buf[0]) / 8;
|
|
|
|
|
int off = ((unsigned char)buf[0]) % 8;
|
|
|
|
|
DEBUGASSERT(Curl_dyn_len(&rtspc->buf) == 1);
|
|
|
|
|
if(!(data->state.rtp_channel_mask[idx] & (1 << off))) {
|
|
|
|
|
/* invalid channel number, junk or BODY data */
|
|
|
|
|
rtspc->state = RTP_PARSE_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
|
|
|
DEBUGASSERT(skip_len == 0);
|
|
|
|
|
/* we do not consume this byte, it is BODY data */
|
|
|
|
|
DEBUGF(infof(data, "RTSP: invalid RTP channel %d, skipping", idx));
|
|
|
|
|
if(*pconsumed == 0) {
|
|
|
|
|
/* We did not consume the initial '$' in our buffer, but had
|
|
|
|
|
* it from an earlier call. We cannot un-consume it and have
|
|
|
|
|
* to write it directly as BODY data */
|
|
|
|
|
result = rtp_write_body_junk(data, Curl_dyn_ptr(&rtspc->buf), 1);
|
|
|
|
|
if(result)
|
2023-10-07 21:13:09 +08:00
|
|
|
goto out;
|
2023-03-21 15:45:59 +08:00
|
|
|
}
|
2023-10-07 21:13:09 +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
|
|
|
/* count the '$' as skip and continue */
|
|
|
|
|
skip_len = 1;
|
2023-03-21 15:45:59 +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_free(&rtspc->buf);
|
2023-10-07 21:13:09 +08:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
/* a valid channel, so we expect this to be a real RTP message */
|
|
|
|
|
rtspc->rtp_channel = (unsigned char)buf[0];
|
|
|
|
|
if(Curl_dyn_addn(&rtspc->buf, buf, 1)) {
|
|
|
|
|
result = CURLE_OUT_OF_MEMORY;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
*pconsumed += 1;
|
|
|
|
|
++buf;
|
|
|
|
|
--blen;
|
|
|
|
|
rtspc->state = RTP_PARSE_LEN;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2023-10-07 21:13:09 +08:00
|
|
|
case RTP_PARSE_LEN: {
|
|
|
|
|
size_t rtp_len = Curl_dyn_len(&rtspc->buf);
|
|
|
|
|
const char *rtp_buf;
|
|
|
|
|
DEBUGASSERT(rtp_len >= 2 && rtp_len < 4);
|
|
|
|
|
if(Curl_dyn_addn(&rtspc->buf, buf, 1)) {
|
|
|
|
|
result = CURLE_OUT_OF_MEMORY;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
*pconsumed += 1;
|
|
|
|
|
++buf;
|
|
|
|
|
--blen;
|
|
|
|
|
if(rtp_len == 2)
|
|
|
|
|
break;
|
|
|
|
|
rtp_buf = Curl_dyn_ptr(&rtspc->buf);
|
|
|
|
|
rtspc->rtp_len = RTP_PKT_LENGTH(rtp_buf) + 4;
|
|
|
|
|
rtspc->state = RTP_PARSE_DATA;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2023-03-21 15:45:59 +08:00
|
|
|
|
2023-10-07 21:13:09 +08:00
|
|
|
case RTP_PARSE_DATA: {
|
|
|
|
|
size_t rtp_len = Curl_dyn_len(&rtspc->buf);
|
|
|
|
|
size_t needed;
|
|
|
|
|
DEBUGASSERT(rtp_len < rtspc->rtp_len);
|
|
|
|
|
needed = rtspc->rtp_len - rtp_len;
|
|
|
|
|
if(needed <= blen) {
|
|
|
|
|
if(Curl_dyn_addn(&rtspc->buf, buf, needed)) {
|
|
|
|
|
result = CURLE_OUT_OF_MEMORY;
|
|
|
|
|
goto out;
|
2023-03-21 15:45:59 +08:00
|
|
|
}
|
2023-10-07 21:13:09 +08:00
|
|
|
*pconsumed += needed;
|
|
|
|
|
buf += needed;
|
|
|
|
|
blen -= needed;
|
|
|
|
|
/* complete RTP message in buffer */
|
|
|
|
|
DEBUGF(infof(data, "RTP write channel %d rtp_len %zu",
|
|
|
|
|
rtspc->rtp_channel, rtspc->rtp_len));
|
|
|
|
|
result = rtp_client_write(data, Curl_dyn_ptr(&rtspc->buf),
|
|
|
|
|
rtspc->rtp_len);
|
|
|
|
|
Curl_dyn_free(&rtspc->buf);
|
|
|
|
|
rtspc->state = RTP_PARSE_SKIP;
|
|
|
|
|
if(result)
|
|
|
|
|
goto out;
|
2023-03-21 15:45:59 +08:00
|
|
|
}
|
|
|
|
|
else {
|
2023-10-07 21:13:09 +08:00
|
|
|
if(Curl_dyn_addn(&rtspc->buf, buf, blen)) {
|
|
|
|
|
result = CURLE_OUT_OF_MEMORY;
|
|
|
|
|
goto out;
|
2023-03-21 15:45:59 +08:00
|
|
|
}
|
2023-10-07 21:13:09 +08:00
|
|
|
*pconsumed += blen;
|
|
|
|
|
buf += blen;
|
|
|
|
|
blen = 0;
|
2023-03-21 15:45:59 +08:00
|
|
|
}
|
2023-10-07 21:13:09 +08:00
|
|
|
break;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
2023-10-07 21:13:09 +08:00
|
|
|
default:
|
|
|
|
|
DEBUGASSERT(0);
|
|
|
|
|
return CURLE_RECV_ERROR;
|
2023-03-17 22:26:00 +08:00
|
|
|
}
|
2023-10-07 21:13:09 +08:00
|
|
|
}
|
|
|
|
|
out:
|
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(!result && skip_len)
|
|
|
|
|
result = rtp_write_body_junk(data, (char *)(buf - skip_len), skip_len);
|
2023-10-07 21:13:09 +08:00
|
|
|
return result;
|
|
|
|
|
}
|
2010-01-28 09:39:16 +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 CURLcode rtsp_rtp_write_resp(struct Curl_easy *data,
|
|
|
|
|
const char *buf,
|
|
|
|
|
size_t blen,
|
2024-03-11 19:35:07 +08:00
|
|
|
bool is_eos)
|
2023-10-07 21:13:09 +08:00
|
|
|
{
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
struct rtsp_conn *rtspc = &(data->conn->proto.rtspc);
|
2023-10-07 21:13:09 +08:00
|
|
|
CURLcode result = CURLE_OK;
|
|
|
|
|
size_t consumed = 0;
|
|
|
|
|
|
|
|
|
|
if(!data->req.header)
|
|
|
|
|
rtspc->in_header = FALSE;
|
|
|
|
|
if(!blen) {
|
|
|
|
|
goto out;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
DEBUGF(infof(data, "rtsp_rtp_write_resp(len=%zu, in_header=%d, eos=%d)",
|
|
|
|
|
blen, rtspc->in_header, is_eos));
|
|
|
|
|
|
2024-04-10 15:36:10 +08:00
|
|
|
/* If header parsing is not ongoing, extract RTP messages */
|
2023-10-07 21:13:09 +08:00
|
|
|
if(!rtspc->in_header) {
|
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 = rtsp_filter_rtp(data, buf, blen, &consumed);
|
2023-10-07 21:13:09 +08:00
|
|
|
if(result)
|
|
|
|
|
goto out;
|
|
|
|
|
buf += consumed;
|
|
|
|
|
blen -= consumed;
|
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
|
|
|
/* either we consumed all or are at the start of header parsing */
|
2024-01-19 17:15:03 +08:00
|
|
|
if(blen && !data->req.header)
|
|
|
|
|
DEBUGF(infof(data, "RTSP: %zu bytes, possibly excess in response body",
|
|
|
|
|
blen));
|
2023-10-07 21:13:09 +08:00
|
|
|
}
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2023-10-07 21:13:09 +08:00
|
|
|
/* we want to parse headers, do so */
|
|
|
|
|
if(data->req.header && blen) {
|
|
|
|
|
rtspc->in_header = TRUE;
|
2024-03-11 19:35:07 +08:00
|
|
|
result = Curl_http_write_resp_hds(data, buf, blen, &consumed);
|
2023-10-07 21:13:09 +08:00
|
|
|
if(result)
|
|
|
|
|
goto out;
|
|
|
|
|
|
2023-11-07 00:06:06 +08:00
|
|
|
buf += consumed;
|
|
|
|
|
blen -= consumed;
|
2023-10-07 21:13:09 +08:00
|
|
|
|
|
|
|
|
if(!data->req.header)
|
|
|
|
|
rtspc->in_header = FALSE;
|
|
|
|
|
|
|
|
|
|
if(!rtspc->in_header) {
|
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 header parsing is done, extract interleaved RTP messages */
|
2024-01-15 18:33:13 +08:00
|
|
|
if(data->req.size <= -1) {
|
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
|
|
|
/* Respect section 4.4 of rfc2326: If the Content-Length header is
|
2024-01-15 18:33:13 +08:00
|
|
|
absent, a length 0 must be assumed. */
|
|
|
|
|
data->req.size = 0;
|
lib: replace readwrite with write_resp
This clarifies the handling of server responses by folding the code for
the complicated protocols into their protocol handlers. This concerns
mainly HTTP and its bastard sibling RTSP.
The terms "read" and "write" are often used without clear context if
they refer to the connect or the client/application side of a
transfer. This PR uses "read/write" for operations on the client side
and "send/receive" for the connection, e.g. server side. If this is
considered useful, we can revisit renaming of further methods in another
PR.
Curl's protocol handler `readwrite()` method been changed:
```diff
- CURLcode (*readwrite)(struct Curl_easy *data, struct connectdata *conn,
- const char *buf, size_t blen,
- size_t *pconsumed, bool *readmore);
+ CURLcode (*write_resp)(struct Curl_easy *data, const char *buf, size_t blen,
+ bool is_eos, bool *done);
```
The name was changed to clarify that this writes reponse data to the
client side. The parameter changes are:
* `conn` removed as it always operates on `data->conn`
* `pconsumed` removed as the method needs to handle all data on success
* `readmore` removed as no longer necessary
* `is_eos` as indicator that this is the last call for the transfer
response (end-of-stream).
* `done` TRUE on return iff the transfer response is to be treated as
finished
This change affects many files only because of updated comments in
handlers that provide no implementation. The real change is that the
HTTP protocol handlers now provide an implementation.
The HTTP protocol handlers `write_resp()` implementation will get passed
**all** raw data of a server response for the transfer. The HTTP/1.x
formatted status and headers, as well as the undecoded response
body. `Curl_http_write_resp_hds()` is used internally to parse the
response headers and pass them on. This method is public as the RTSP
protocol handler also uses it.
HTTP/1.1 "chunked" transport encoding is now part of the general
*content encoding* writer stack, just like other encodings. A new flag
`CLIENTWRITE_EOS` was added for the last client write. This allows
writers to verify that they are in a valid end state. The chunked
decoder will check if it indeed has seen the last chunk.
The general response handling in `transfer.c:466` happens in function
`readwrite_data()`. This mainly operates now like:
```
static CURLcode readwrite_data(data, ...)
{
do {
Curl_xfer_recv_resp(data, buf)
...
Curl_xfer_write_resp(data, buf)
...
} while(interested);
...
}
```
All the response data handling is implemented in
`Curl_xfer_write_resp()`. It calls the protocol handler's `write_resp()`
implementation if available, or does the default behaviour.
All raw response data needs to pass through this function. Which also
means that anyone in possession of such data may call
`Curl_xfer_write_resp()`.
Closes #12480
2023-12-01 20:50:32 +08:00
|
|
|
data->req.download_done = TRUE;
|
|
|
|
|
}
|
|
|
|
|
result = rtsp_filter_rtp(data, buf, blen, &consumed);
|
2023-10-07 21:13:09 +08:00
|
|
|
if(result)
|
|
|
|
|
goto out;
|
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
|
|
|
blen -= consumed;
|
2023-10-07 21:13:09 +08:00
|
|
|
}
|
|
|
|
|
}
|
2010-01-21 21:58:30 +08:00
|
|
|
|
2023-10-07 21:13:09 +08:00
|
|
|
if(rtspc->state != RTP_PARSE_SKIP)
|
2024-03-11 19:35:07 +08:00
|
|
|
data->req.done = FALSE;
|
2024-01-15 18:33:13 +08:00
|
|
|
/* we SHOULD have consumed all bytes, unless the response is borked.
|
|
|
|
|
* In which case we write out the left over bytes, letting the client
|
|
|
|
|
* writer deal with it (it will report EXCESS and fail the transfer). */
|
|
|
|
|
DEBUGF(infof(data, "rtsp_rtp_write_resp(len=%zu, in_header=%d, done=%d "
|
|
|
|
|
" rtspc->state=%d, req.size=%" CURL_FORMAT_CURL_OFF_T ")",
|
2024-03-11 19:35:07 +08:00
|
|
|
blen, rtspc->in_header, data->req.done, rtspc->state,
|
|
|
|
|
data->req.size));
|
2024-01-15 18:33:13 +08:00
|
|
|
if(!result && (is_eos || blen)) {
|
|
|
|
|
result = Curl_client_write(data, CLIENTWRITE_BODY|
|
|
|
|
|
(is_eos? CLIENTWRITE_EOS:0),
|
|
|
|
|
(char *)buf, 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
|
|
|
}
|
2023-10-07 21:13:09 +08:00
|
|
|
|
|
|
|
|
out:
|
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.rtspreq == RTSPREQ_RECEIVE) &&
|
|
|
|
|
(rtspc->state == RTP_PARSE_SKIP)) {
|
2023-10-07 21:13:09 +08:00
|
|
|
/* In special mode RECEIVE, we just process one chunk of network
|
|
|
|
|
* data, so we stop the transfer here, if we have no incomplete
|
|
|
|
|
* RTP message pending. */
|
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.download_done = TRUE;
|
2023-10-07 21:13:09 +08:00
|
|
|
}
|
|
|
|
|
return result;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
|
2010-01-25 12:36:13 +08:00
|
|
|
static
|
2023-10-07 21:13:09 +08:00
|
|
|
CURLcode rtp_client_write(struct Curl_easy *data, const char *ptr, size_t len)
|
2010-01-21 21:58:30 +08:00
|
|
|
{
|
|
|
|
|
size_t wrote;
|
|
|
|
|
curl_write_callback writeit;
|
2017-09-13 02:45:19 +08:00
|
|
|
void *user_ptr;
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
if(len == 0) {
|
2016-12-14 06:34:59 +08:00
|
|
|
failf(data, "Cannot write a 0 size RTP packet.");
|
2010-01-21 21:58:30 +08:00
|
|
|
return CURLE_WRITE_ERROR;
|
|
|
|
|
}
|
|
|
|
|
|
2017-09-13 02:45:19 +08:00
|
|
|
/* If the user has configured CURLOPT_INTERLEAVEFUNCTION then use that
|
|
|
|
|
function and any configured CURLOPT_INTERLEAVEDATA to write out the RTP
|
|
|
|
|
data. Otherwise, use the CURLOPT_WRITEFUNCTION with the CURLOPT_WRITEDATA
|
|
|
|
|
pointer to write out the RTP data. */
|
|
|
|
|
if(data->set.fwrite_rtp) {
|
|
|
|
|
writeit = data->set.fwrite_rtp;
|
|
|
|
|
user_ptr = data->set.rtp_out;
|
|
|
|
|
}
|
2018-04-26 03:53:27 +08:00
|
|
|
else {
|
2017-09-13 02:45:19 +08:00
|
|
|
writeit = data->set.fwrite_func;
|
|
|
|
|
user_ptr = data->set.out;
|
2017-09-08 16:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
2018-02-10 22:13:15 +08:00
|
|
|
Curl_set_in_callback(data, true);
|
2023-10-07 21:13:09 +08:00
|
|
|
wrote = writeit((char *)ptr, 1, len, user_ptr);
|
2018-02-10 22:13:15 +08:00
|
|
|
Curl_set_in_callback(data, false);
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
if(CURL_WRITEFUNC_PAUSE == wrote) {
|
2016-12-14 06:34:59 +08:00
|
|
|
failf(data, "Cannot pause RTP");
|
2010-01-21 21:58:30 +08:00
|
|
|
return CURLE_WRITE_ERROR;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(wrote != len) {
|
2016-12-14 06:34:59 +08:00
|
|
|
failf(data, "Failed writing RTP data");
|
2010-01-21 21:58:30 +08:00
|
|
|
return CURLE_WRITE_ERROR;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return CURLE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-21 19:15:59 +08:00
|
|
|
CURLcode Curl_rtsp_parseheader(struct Curl_easy *data, const char *header)
|
2010-01-21 21:58:30 +08:00
|
|
|
{
|
|
|
|
|
if(checkprefix("CSeq:", header)) {
|
2023-02-25 00:31:43 +08:00
|
|
|
long CSeq = 0;
|
|
|
|
|
char *endp;
|
2024-03-21 19:15:59 +08:00
|
|
|
const char *p = &header[5];
|
2023-02-25 00:31:43 +08:00
|
|
|
while(ISBLANK(*p))
|
|
|
|
|
p++;
|
|
|
|
|
CSeq = strtol(p, &endp, 10);
|
|
|
|
|
if(p != endp) {
|
2020-11-23 15:32:41 +08:00
|
|
|
struct RTSP *rtsp = data->req.p.rtsp;
|
2013-08-05 16:32:08 +08:00
|
|
|
rtsp->CSeq_recv = CSeq; /* mark the request */
|
2010-01-21 21:58:30 +08:00
|
|
|
data->state.rtsp_CSeq_recv = CSeq; /* update the handle */
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
failf(data, "Unable to read the CSeq header: [%s]", header);
|
|
|
|
|
return CURLE_RTSP_CSEQ_ERROR;
|
|
|
|
|
}
|
2010-01-28 09:39:16 +08:00
|
|
|
}
|
2010-01-21 21:58:30 +08:00
|
|
|
else if(checkprefix("Session:", header)) {
|
2024-03-21 19:15:59 +08:00
|
|
|
const char *start, *end;
|
2020-11-03 22:55:58 +08:00
|
|
|
size_t idlen;
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
/* Find the first non-space letter */
|
2014-03-20 18:52:27 +08:00
|
|
|
start = header + 8;
|
2022-09-06 05:21:15 +08:00
|
|
|
while(*start && ISBLANK(*start))
|
2010-01-21 21:58:30 +08:00
|
|
|
start++;
|
|
|
|
|
|
2010-09-06 22:03:37 +08:00
|
|
|
if(!*start) {
|
2010-01-21 21:58:30 +08:00
|
|
|
failf(data, "Got a blank Session ID");
|
2020-11-03 22:55:58 +08:00
|
|
|
return CURLE_RTSP_SESSION_ERROR;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
2020-11-03 09:36:56 +08:00
|
|
|
|
2020-11-03 22:55:58 +08:00
|
|
|
/* Find the end of Session ID
|
|
|
|
|
*
|
|
|
|
|
* Allow any non whitespace content, up to the field separator or end of
|
2024-07-01 22:47:21 +08:00
|
|
|
* line. RFC 2326 is not 100% clear on the session ID and for example
|
2020-11-03 22:55:58 +08:00
|
|
|
* gstreamer does url-encoded session ID's not covered by the standard.
|
|
|
|
|
*/
|
|
|
|
|
end = start;
|
|
|
|
|
while(*end && *end != ';' && !ISSPACE(*end))
|
|
|
|
|
end++;
|
|
|
|
|
idlen = end - start;
|
|
|
|
|
|
|
|
|
|
if(data->set.str[STRING_RTSP_SESSION_ID]) {
|
2020-11-03 09:36:56 +08:00
|
|
|
|
2010-01-21 21:58:30 +08:00
|
|
|
/* If the Session ID is set, then compare */
|
2020-11-03 09:36:56 +08:00
|
|
|
if(strlen(data->set.str[STRING_RTSP_SESSION_ID]) != idlen ||
|
2023-12-05 22:55:35 +08:00
|
|
|
strncmp(start, data->set.str[STRING_RTSP_SESSION_ID], idlen)) {
|
2010-01-21 21:58:30 +08:00
|
|
|
failf(data, "Got RTSP Session ID Line [%s], but wanted ID [%s]",
|
|
|
|
|
start, data->set.str[STRING_RTSP_SESSION_ID]);
|
|
|
|
|
return CURLE_RTSP_SESSION_ERROR;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
2016-08-10 14:58:10 +08:00
|
|
|
/* If the Session ID is not set, and we find it in a response, then set
|
|
|
|
|
* it.
|
|
|
|
|
*/
|
2010-01-21 21:58:30 +08:00
|
|
|
|
|
|
|
|
/* Copy the id substring into a new buffer */
|
2023-12-08 21:27:29 +08:00
|
|
|
data->set.str[STRING_RTSP_SESSION_ID] = Curl_memdup0(start, idlen);
|
2021-04-19 16:46:11 +08:00
|
|
|
if(!data->set.str[STRING_RTSP_SESSION_ID])
|
2010-02-03 21:28:47 +08:00
|
|
|
return CURLE_OUT_OF_MEMORY;
|
2010-01-21 21:58:30 +08:00
|
|
|
}
|
|
|
|
|
}
|
2023-03-21 15:45:59 +08:00
|
|
|
else if(checkprefix("Transport:", header)) {
|
|
|
|
|
CURLcode result;
|
|
|
|
|
result = rtsp_parse_transport(data, header + 10);
|
|
|
|
|
if(result)
|
|
|
|
|
return result;
|
|
|
|
|
}
|
2010-01-21 21:58:30 +08:00
|
|
|
return CURLE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-21 15:45:59 +08:00
|
|
|
static
|
2024-03-21 19:15:59 +08:00
|
|
|
CURLcode rtsp_parse_transport(struct Curl_easy *data, const char *transport)
|
2023-03-21 15:45:59 +08:00
|
|
|
{
|
|
|
|
|
/* If we receive multiple Transport response-headers, the linterleaved
|
|
|
|
|
channels of each response header is recorded and used together for
|
|
|
|
|
subsequent data validity checks.*/
|
|
|
|
|
/* e.g.: ' RTP/AVP/TCP;unicast;interleaved=5-6' */
|
2024-03-21 19:15:59 +08:00
|
|
|
const char *start, *end;
|
2023-03-21 15:45:59 +08:00
|
|
|
start = transport;
|
|
|
|
|
while(start && *start) {
|
|
|
|
|
while(*start && ISBLANK(*start) )
|
|
|
|
|
start++;
|
|
|
|
|
end = strchr(start, ';');
|
|
|
|
|
if(checkprefix("interleaved=", start)) {
|
|
|
|
|
long chan1, chan2, chan;
|
|
|
|
|
char *endp;
|
2024-03-21 19:15:59 +08:00
|
|
|
const char *p = start + 12;
|
2023-03-21 15:45:59 +08:00
|
|
|
chan1 = strtol(p, &endp, 10);
|
|
|
|
|
if(p != endp && chan1 >= 0 && chan1 <= 255) {
|
|
|
|
|
unsigned char *rtp_channel_mask = data->state.rtp_channel_mask;
|
|
|
|
|
chan2 = chan1;
|
|
|
|
|
if(*endp == '-') {
|
|
|
|
|
p = endp + 1;
|
|
|
|
|
chan2 = strtol(p, &endp, 10);
|
|
|
|
|
if(p == endp || chan2 < 0 || chan2 > 255) {
|
|
|
|
|
infof(data, "Unable to read the interleaved parameter from "
|
|
|
|
|
"Transport header: [%s]", transport);
|
|
|
|
|
chan2 = chan1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
for(chan = chan1; chan <= chan2; chan++) {
|
|
|
|
|
long idx = chan / 8;
|
|
|
|
|
long off = chan % 8;
|
|
|
|
|
rtp_channel_mask[idx] |= (unsigned char)(1 << off);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
infof(data, "Unable to read the interleaved parameter from "
|
|
|
|
|
"Transport header: [%s]", transport);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
/* skip to next parameter */
|
|
|
|
|
start = (!end) ? end : (end + 1);
|
|
|
|
|
}
|
|
|
|
|
return CURLE_OK;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2020-12-14 21:10:33 +08:00
|
|
|
#endif /* CURL_DISABLE_RTSP or using Hyper */
|
