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