summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorTom Vrancken <dev@tomvrancken.nl>2018-05-20 10:23:36 +0200
committerTom Vrancken <dev@tomvrancken.nl>2018-05-23 10:20:09 +0200
commit4d4ce950f2b51879c2f87df90a9bff33bfcb2180 (patch)
tree4a54274b770b52a5d90fb7505ed8664fa2843188 /doc
parent0a4750e613c3eec6c29e1eb29aebe35b58665915 (diff)
downloadgnutls-4d4ce950f2b51879c2f87df90a9bff33bfcb2180.tar.gz
Fixed typo and incorrect function references.
Signed-off-by: Tom Vrancken <dev@tomvrancken.nl>
Diffstat (limited to 'doc')
-rw-r--r--doc/cha-internals.texi52
1 files changed, 26 insertions, 26 deletions
diff --git a/doc/cha-internals.texi b/doc/cha-internals.texi
index 18c8bf9d40..5c9e770c40 100644
--- a/doc/cha-internals.texi
+++ b/doc/cha-internals.texi
@@ -124,11 +124,11 @@ inside an application using GnuTLS) and register it via the exported functions
@subheading Adding a new TLS hello extension
Adding support for a new TLS hello extension is done from time to time, and
-the process to do so is not difficult. Here are the steps you need to
-follow if you wish to do this yourself. For the sake of discussion, let's
-consider adding support for the hypothetical TLS extension
-@code{foobar}. The following section is about adding an hello extension to
-GnuTLS itself. For custom application extensions you should check the exported functions
+the process to do so is not difficult. Here are the steps you need to
+follow if you wish to do this yourself. For the sake of discussion, let's
+consider adding support for the hypothetical TLS extension @code{foobar}.
+The following section is about adding an hello extension to GnuTLS itself.
+For custom application extensions you should check the exported functions
@funcref{gnutls_session_ext_register} or @funcref{gnutls_ext_register}.
@subsubheading Add @code{configure} option like @code{--enable-foobar} or @code{--disable-foobar}.
@@ -137,7 +137,7 @@ This step is useful when the extension code is large and it might be desirable
under some circumstances to be able to leave out the extension during compilation of GnuTLS.
If you don't need this kind of feature this step can be safely skipped.
-Whether to chooe enable or disable depends on whether you intend to make the extension be
+Whether to choose enable or disable depends on whether you intend to make the extension be
enabled by default. Look at existing checks (i.e., SRP, authz) for
how to model the code. For example:
@@ -181,28 +181,28 @@ A typical entry would be:
#endif
@end example
-Also for every extension you need to create @code{hello_ext_entry_st}
+Also for every extension you need to create an @code{hello_ext_entry_st}
that describes the extension. This structure is placed in the designated
c file for your extension and its name is used in the registration entry
as depicted above.
The structure of @code{hello_ext_entry_st} is as follows:
@example
- const hello_ext_entry_st ext_mod_foobar = @{
- .name = "FOOBAR",
- .tls_id = 255,
- .gid = GNUTLS_EXTENSION_FOOBAR,
- .parse_type = GNUTLS_EXT_TLS,
- .validity = GNUTLS_EXT_FLAG_CLIENT_HELLO |
- GNUTLS_EXT_FLAG_TLS12_SERVER_HELLO |
- GNUTLS_EXT_FLAG_TLS13_SERVER_HELLO,
- .recv_func = _gnutls_foobar_recv_params,
- .send_func = _gnutls_foobar_send_params,
- .pack_func = _gnutls_foobar_pack,
- .unpack_func = _gnutls_foobar_unpack,
- .deinit_func = _gnutls_foobar_deinit,
- .cannot_be_overriden = 1
- @};
+ const hello_ext_entry_st ext_mod_foobar = @{
+ .name = "FOOBAR",
+ .tls_id = 255,
+ .gid = GNUTLS_EXTENSION_FOOBAR,
+ .parse_type = GNUTLS_EXT_TLS,
+ .validity = GNUTLS_EXT_FLAG_CLIENT_HELLO |
+ GNUTLS_EXT_FLAG_TLS12_SERVER_HELLO |
+ GNUTLS_EXT_FLAG_TLS13_SERVER_HELLO,
+ .recv_func = _gnutls_foobar_recv_params,
+ .send_func = _gnutls_foobar_send_params,
+ .pack_func = _gnutls_foobar_pack,
+ .unpack_func = _gnutls_foobar_unpack,
+ .deinit_func = _gnutls_foobar_deinit,
+ .cannot_be_overriden = 1
+ @};
@end example
The GNUTLS_EXTENSION_FOOBAR is the identifier that you've added to
@@ -280,9 +280,9 @@ other error codes from the list in @ref{Error codes}. Return 0 on success.
An extension typically stores private information in the @code{session}
data for later usage. That can be done using the functions
-@funcintref{_gnutls_ext_set_session_data} and
-@funcintref{_gnutls_ext_get_session_data}. You can check simple examples
-at @code{ext/@-max_@-record.c} and @code{ext/@-server_@-name.c} extensions.
+@funcintref{_gnutls_hello_ext_set_priv} and
+@funcintref{_gnutls_hello_ext_get_priv}. You can check simple examples
+at @code{lib/ext/@-max_@-record.c} and @code{lib/ext/@-server_@-name.c} extensions.
That private information can be saved and restored across session
resumption if the following functions are set:
@@ -350,7 +350,7 @@ forget to add @code{Since:} tags to indicate the GnuTLS version the
API was introduced in.
@subsubheading Heartbeat extension.
-
+%REMARK: do we need this section?
One such extension is HeartBeat protocol (RFC6520:
@url{https://tools.ietf.org/html/rfc6520}) implementation. To enable
it use option --heartbeat with example client and server supplied with