]> git.ipfire.org Git - thirdparty/openssl.git/blobdiff - doc/man3/OSSL_HTTP_transfer.pod
Copyright year updates
[thirdparty/openssl.git] / doc / man3 / OSSL_HTTP_transfer.pod
index e44ee9761efb3ab3017d67e37713b77d181a9daa..e0375377e66c87a82dc0fb5b40a963ba2f7c099f 100644 (file)
@@ -161,17 +161,28 @@ NULL) to print additional diagnostic information in a user-oriented way.
 
 OSSL_HTTP_set1_request() sets up in I<rctx> the request header and content data
 and expectations on the response using the following parameters.
-If <rctx> indicates using a proxy for HTTP (but not HTTPS), the server hostname
-(and optionally port) needs to be placed in the header and thus must be present.
+If <rctx> indicates using a proxy for HTTP (but not HTTPS), the server host
+(and optionally port) needs to be placed in the header; thus it must be present
+in I<rctx>.
+For backward compatibility, the server (and optional port) may also be given in
+the I<path> argument beginning with C<http://> (thus giving an absoluteURI).
 If I<path> is NULL it defaults to "/".
 If I<req> is NULL the HTTP GET method will be used to send the request
 else HTTP POST with the contents of I<req> and optional I<content_type>, where
 the length of the data in I<req> does not need to be determined in advance: the
 BIO will be read on-the-fly while sending the request, which supports streaming.
 The optional list I<headers> may contain additional custom HTTP header lines.
-If the parameter I<expected_content_type>
-is not NULL then the client will check that the given content type string
+
+If the I<expected_content_type> argument is not NULL,
+the client will check that the specified content-type string
 is included in the HTTP header of the response and return an error if not.
+In the content-type header line the specified string should be present either
+as a whole, or in case the specified string does not include a C<;> character,
+it is sufficient that the specified string appears as a prefix
+in the header line, followed by a C<;> character and any further text.
+For instance, if I<expected_content_type> specifies C<text/html>,
+this is matched by C<text/html>, C<text/html; charset=UTF-8>, etc.
+
 If the I<expect_asn1> parameter is nonzero,
 a structure in ASN.1 encoding will be expected as response content.
 The I<max_resp_len> parameter specifies the maximum allowed
@@ -202,7 +213,7 @@ an ASN.1-encoded response is expected, which should include a total length,
 the length indications received are checked for consistency
 and for not exceeding any given maximum response length.
 If an ASN.1-encoded response is expected, the function returns on success
-the contents as a memory BIO, which does not support streaming.
+the contents buffered in a memory BIO, which does not support streaming.
 Otherwise it returns directly the read BIO that holds the response contents,
 which allows a response of indefinite length and may support streaming.
 The caller is responsible for freeing the BIO pointer obtained.
@@ -257,8 +268,8 @@ OSSL_HTTP_proxy_connect() and OSSL_HTTP_set1_request()
 return 1 on success, 0 on error.
 
 On success, OSSL_HTTP_exchange(), OSSL_HTTP_get(), and OSSL_HTTP_transfer()
-return a memory BIO containing the data received if an ASN.1-encoded response
-is expected, else a BIO that may support streaming.
+return a memory BIO that buffers all the data received if an ASN.1-encoded
+response is expected, otherwise a BIO that may support streaming.
 The BIO must be freed by the caller.
 On failure, they return NULL.
 Failure conditions include connection/transfer timeout, parse errors, etc.
@@ -279,7 +290,7 @@ All the functions described here were added in OpenSSL 3.0.
 
 =head1 COPYRIGHT
 
-Copyright 2019-2021 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy