diff --git a/lib/libwebsockets.c b/lib/libwebsockets.c
index 860dee88..43ede68f 100644
--- a/lib/libwebsockets.c
+++ b/lib/libwebsockets.c
@@ -654,7 +654,17 @@ lws_get_addresses(struct lws_context *context, void *ads, char *name,
#endif
}
-const char *
+/**
+ * lws_get_peer_simple() - Get client address information without RDNS
+ * @wsi: Local struct lws associated with
+ * @name: Buffer to take client address name
+ * @name_len: Length of client address name buffer
+ *
+ * This provides a 123.123.123.123 type IP address in @name from the
+ * peer that has connected to @wsi
+ */
+
+LWS_VISIBLE const char *
lws_get_peer_simple(struct lws *wsi, char *name, int namelen)
{
#if LWS_POSIX
diff --git a/lib/libwebsockets.h b/lib/libwebsockets.h
index 21debc13..f2f9fc90 100644
--- a/lib/libwebsockets.h
+++ b/lib/libwebsockets.h
@@ -1987,6 +1987,9 @@ LWS_VISIBLE LWS_EXTERN void
lws_get_peer_addresses(struct lws *wsi, lws_sockfd_type fd, char *name,
int name_len, char *rip, int rip_len);
+LWS_VISIBLE LWS_EXTERN const char *
+lws_get_peer_simple(struct lws *wsi, char *name, int namelen);
+
LWS_VISIBLE LWS_EXTERN int
lws_get_random(struct lws_context *context, void *buf, int len);
diff --git a/lib/private-libwebsockets.h b/lib/private-libwebsockets.h
index ab06b9d4..8450c43c 100644
--- a/lib/private-libwebsockets.h
+++ b/lib/private-libwebsockets.h
@@ -1722,9 +1722,6 @@ LWS_EXTERN int
lws_get_addresses(struct lws_context *context, void *ads, char *name,
int name_len, char *rip, int rip_len);
-LWS_EXTERN const char *
-lws_get_peer_simple(struct lws *wsi, char *name, int namelen);
-
#ifdef LWS_WITH_ACCESS_LOG
LWS_EXTERN int
lws_access_log(struct lws *wsi);
diff --git a/libwebsockets-api-doc.html b/libwebsockets-api-doc.html
index 80ccd376..504f4f55 100644
--- a/libwebsockets-api-doc.html
+++ b/libwebsockets-api-doc.html
@@ -166,6 +166,40 @@ representing the library version followed by the git head hash it
was built from
+lws_init_vhost_client_ssl - also enable client SSL on an existing vhost
+int
+lws_init_vhost_client_ssl
+(const struct lws_context_creation_info * info,
+struct lws_vhost * vhost)
+Arguments
+
+- info
+
- client ssl related info
+
- vhost
+
- which vhost to initialize client ssl operations on
+
+Description
+
+You only need to call this if you plan on using SSL client connections on
+the vhost. For non-SSL client connections, it's not necessary to call this.
+
+The following members of info are used during the call
+
+- options must have LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT set,
+otherwise the call does nothing
+- provided_client_ssl_ctx must be NULL to get a generated client
+ssl context, otherwise you can pass a prepared one in by setting it
+- ssl_cipher_list may be NULL or set to the client valid cipher list
+- ssl_ca_filepath may be NULL or client cert filepath
+- ssl_cert_filepath may be NULL or client cert filepath
+- ssl_private_key_filepath may be NULL or client cert private key
+
+You must create your vhost explicitly if you want to use this, so you have
+a pointer to the vhost. Create the context first with the option flag
+LWS_SERVER_OPTION_EXPLICIT_VHOSTS and then call lws_create_vhost with
+the same info struct.
+
+
lws_create_context - Create the websocket handler
struct lws_context *
lws_create_context
@@ -259,6 +293,104 @@ Helper to report HTTP errors back to the client cleanly and
consistently
+lejp_construct - prepare a struct lejp_ctx for use
+void
+lejp_construct
+(struct lejp_ctx * ctx,
+char (*callback) (struct lejp_ctx *ctx, char reason),
+void * user,
+const char *const * paths,
+unsigned char count_paths)
+Arguments
+
+- ctx
+
- pointer to your struct lejp_ctx
+
- callback
+
- your user callback which will received parsed tokens
+
- user
+
- optional user data pointer untouched by lejp
+
- paths
+
- your array of name elements you are interested in
+
- count_paths
+
- ARRAY_SIZE of paths
+
+Description
+
+Prepares your context struct for use with lejp
+
+
+lejp_destruct - retire a previously constructed struct lejp_ctx
+void
+lejp_destruct
+(struct lejp_ctx * ctx)
+Arguments
+
+- ctx
+
- pointer to your struct lejp_ctx
+
+Description
+
+lejp does not perform any allocations, but since your user code might, this
+provides a one-time LEJPCB_DESTRUCTED callback at destruction time where
+you can clean up in your callback.
+
+
+lejp_change_callback - switch to a different callback from now on
+void
+lejp_change_callback
+(struct lejp_ctx * ctx,
+char (*callback) (struct lejp_ctx *ctx, char reason))
+Arguments
+
+- ctx
+
- pointer to your struct lejp_ctx
+
- callback
+
- your user callback which will received parsed tokens
+
+Description
+
+This tells the old callback it was destroyed, in case you want to take any
+action because that callback "lost focus", then changes to the new
+callback and tells it first that it was constructed, and then started.
+
+Changing callback is a cheap and powerful trick to split out handlers
+according to information earlier in the parse. For example you may have
+a JSON pair "schema" whose value defines what can be expected for the rest
+of the JSON. Rather than having one huge callback for all cases, you can
+have an initial one looking for "schema" which then calls
+lejp_change_callback to a handler specific for the schema.
+
+Notice that afterwards, you need to construct the context again anyway to
+parse another JSON object, and the callback is reset then to the main,
+schema-interpreting one. The construction action is very lightweight.
+
+
+lejp_parse - interpret some more incoming data incrementally
+int
+lejp_parse
+(struct lejp_ctx * ctx,
+const unsigned char * json,
+int len)
+Arguments
+
+- ctx
+
- previously constructed parsing context
+
- json
+
- char buffer with the new data to interpret
+
- len
+
- amount of data in the buffer
+
+Description
+
+Because lejp is a stream parser, it incrementally parses as new data
+becomes available, maintaining all state in the context struct. So an
+incomplete JSON is a normal situation, getting you a LEJP_CONTINUE
+return, signalling there's no error but to call again with more data when
+it comes to complete the parsing. Successful parsing completes with a
+0 or positive integer indicating how much of the last input buffer was
+unused.
+
+
lws_set_timeout - marks the wsi as subject to a timeout
void
lws_set_timeout
@@ -280,6 +412,25 @@ consistently
You will not need this unless you are doing something special
+lws_get_peer_simple - Get client address information without RDNS
+const char *
+lws_get_peer_simple
+(struct lws * wsi,
+char * name,
+int namelen)
+Arguments
+
+- wsi
+
- Local struct lws associated with
+
- name
+
- Buffer to take client address name
+
+Description
+
+This provides a 123.123.123.123 type IP address in name from the
+peer that has connected to wsi
+
+
lws_get_peer_addresses - Get client address information
void
lws_get_peer_addresses
@@ -1692,6 +1843,7 @@ header.
const char * log_filepath;
const struct lws_http_mount * mounts;
const char * server_string;
+ unsigned int pt_serv_buf_size;
};
Members
@@ -1813,6 +1965,12 @@ any dropping of initial privileges
- server_string
- CONTEXT: string used in HTTP headers to identify server
software, if NULL, "libwebsockets".
+
- pt_serv_buf_size
+
- CONTEXT: 0 = default of 4096. This buffer is used by
+various service related features including file serving, it
+defines the max chunk of file that can be sent at once.
+At the risk of lws having to buffer failed large sends, it
+can be increased to, eg, 128KiB to improve throughput.
Description