@@ -7,7 +7,7 @@ This HTTP Client library implements a subset of the HTTP/1.1 protocol. Features
7
7
of this library include:
8
8
- Fully synchronous API, to allow applications to completely manage their concurrency and multi-threading.
9
9
- Operations on user supplied buffers, so that applications have complete control of their memory allocation strategy.
10
- - Integration with [http-parser ](https://github.com/nodejs/http-parser ) to handle chunked encoding.
10
+ - Integration with [llhttp ](https://github.com/nodejs/llhttp ) to handle chunked encoding.
11
11
12
12
Feature of HTTP/1.1 not supported in this library:
13
13
- Streaming uploads and downloads. Range requests for partial content responses are highly encouraged with this API.
@@ -110,7 +110,7 @@ If the request has a body it is passed as a parameter to @ref HTTPClient_Send.
110
110
As soon as the response is received from the network it is parsed. The final
111
111
parsed response is represented by the @ref HTTPResponse_t returned from
112
112
@ref HTTPClient_Send. Parsing the HTTP response is done using
113
- [http-parser ](https://github.com/nodejs/http-parser ). http-parser invokes
113
+ [llhttp ](https://github.com/nodejs/llhttp ). llhttp invokes
114
114
callbacks for each section in the HTTP response it finds. Using these callbacks
115
115
the HTTP client library sets the members of @ref HTTPResponse_t to return from
116
116
@ref HTTPClient_Send. The overall flow of @ref HTTPClient_Send is
@@ -125,14 +125,14 @@ can be read from the headers found in @ref HTTPResponse_t.pHeaders. The function
125
125
@ref HTTPClient_ReadHeader reads the headers from an @ref HTTPResponse_t.
126
126
@ref HTTPClient_ReadHeader will re-parse the response in
127
127
@ref HTTPResponse_t.pBuffer, looking for the header field of interest.
128
- Re-parsing involves using http-parser to look at each character starting from
128
+ Re-parsing involves using llhttp to look at each character starting from
129
129
the beginning of @ref HTTPResponse_t.pBuffer until the header field of interest
130
130
is found.
131
131
132
132
If the user application wants to avoid re-parsing @ref HTTPResponse_t.pBuffer,
133
133
then the user application may register a callback in
134
134
@ref HTTPResponse_t.pHeaderParsingCallback. When the HTTP response message is
135
- first received from the network, in @ref HTTPClient_Send, http-parser is invoked
135
+ first received from the network, in @ref HTTPClient_Send, llhttp is invoked
136
136
to parse the response. This first parsing in @ref HTTPClient_Send will invoke
137
137
@ref HTTPResponse_t.pHeaderParsingCallback for each header that is found
138
138
in response. Please see the sequence diagram below for an illustration of when
@@ -161,7 +161,6 @@ then the @ref HTTP_DO_NOT_USE_CUSTOM_CONFIG macro must be defined.
161
161
@see [Configurations](@ref http_config)
162
162
163
163
The following macros can be configured for this library:
164
- - @ref HTTP_MAX_RESPONSE_HEADERS_SIZE_BYTES
165
164
- @ref HTTP_USER_AGENT_VALUE
166
165
- @ref HTTP_SEND_RETRY_TIMEOUT_MS
167
166
- @ref HTTP_RECV_RETRY_TIMEOUT_MS
@@ -243,9 +242,6 @@ config macros defined in core_http_config_defaults.h file.
243
242
If a custom config is provided, then HTTP_DO_NOT_USE_CUSTOM_CONFIG should not be
244
243
defined.
245
244
246
- @section HTTP_MAX_RESPONSE_HEADERS_SIZE_BYTES
247
- @copydoc HTTP_MAX_RESPONSE_HEADERS_SIZE_BYTES
248
-
249
245
@section HTTP_USER_AGENT_VALUE
250
246
@copydoc HTTP_USER_AGENT_VALUE
251
247
0 commit comments