From 01767198f2e54636651e0bcc5d24370c09fb4012 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C5=99emysl=20Eric=20Janouch?= Date: Wed, 14 Oct 2020 00:00:04 +0200 Subject: WebSockets -> WebSocket This is the correct name of the protocol, usage of the word "WebSockets" should be limited. --- README.adoc | 2 +- json-rpc-shell.adoc | 4 ++-- json-rpc-shell.c | 8 ++++---- json-rpc-test-server.c | 16 ++++++++-------- 4 files changed, 15 insertions(+), 15 deletions(-) diff --git a/README.adoc b/README.adoc index 8cceb1e..fc4db76 100644 --- a/README.adoc +++ b/README.adoc @@ -17,7 +17,7 @@ you get the following niceties: - ability to pipe output through a shell command, so that you can view the results in your favourite editor or redirect them to a file - ability to edit the input line in your favourite editor as well with Alt+E - - WebSockets (RFC 6455) can also be used as a transport rather than HTTP + - WebSocket (RFC 6455) can also be used as a transport rather than HTTP - support for method name tab completion using OpenRPC discovery Documentation diff --git a/json-rpc-shell.adoc b/json-rpc-shell.adoc index 31f78b7..5944ed2 100644 --- a/json-rpc-shell.adoc +++ b/json-rpc-shell.adoc @@ -114,8 +114,8 @@ the M-e key combination. Both *readline*(3) and *editline*(7) also support multiline editing natively, though you need to press C-v C-j in order to insert newlines. -WebSockets -~~~~~~~~~~ +WebSocket +~~~~~~~~~ The JSON-RPC 2.0 specification doesn't say almost anything about underlying transports. The way it's implemented here is that every request is sent as a single text message. If it has an "id" field, i.e., it's not just diff --git a/json-rpc-shell.c b/json-rpc-shell.c index ea4fba7..8c2d64f 100644 --- a/json-rpc-shell.c +++ b/json-rpc-shell.c @@ -1108,7 +1108,7 @@ g_ctx; // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // HTTP/S and WS/S require significantly different handling. While for HTTP we -// can just use the cURL easy interface, with WebSockets it gets a bit more +// can just use the cURL easy interface, with WebSocket it gets a bit more // complicated and we implement it all by ourselves. // // Luckily on a higher level the application doesn't need to bother itself with @@ -1404,12 +1404,12 @@ on_config_attribute_change (struct config_item *item) } } -// --- WebSockets backend ------------------------------------------------------ +// --- WebSocket backend ------------------------------------------------------- enum ws_handler_state { WS_HANDLER_CONNECTING, ///< Parsing HTTP - WS_HANDLER_OPEN, ///< Parsing WebSockets frames + WS_HANDLER_OPEN, ///< Parsing WebSocket frames WS_HANDLER_CLOSING, ///< Closing the connection WS_HANDLER_CLOSED ///< Dead }; @@ -1442,7 +1442,7 @@ struct ws_context SSL_CTX *ssl_ctx; ///< SSL context SSL *ssl; ///< SSL connection - // WebSockets protocol handling: + // WebSocket protocol handling: enum ws_handler_state state; ///< State char *key; ///< Key for the current handshake diff --git a/json-rpc-test-server.c b/json-rpc-test-server.c index d849b83..ce31b54 100644 --- a/json-rpc-test-server.c +++ b/json-rpc-test-server.c @@ -525,11 +525,11 @@ fcgi_muxer_push (struct fcgi_muxer *self, const void *data, size_t len) } /// @} -// --- WebSockets -------------------------------------------------------------- -/// @defgroup WebSockets +// --- WebSocket --------------------------------------------------------------- +/// @defgroup WebSocket /// @{ -// WebSockets aren't CGI-compatible, therefore we must handle the initial HTTP +// WebSocket isn't CGI-compatible, therefore we must handle the initial HTTP // handshake ourselves. Luckily it's not too much of a bother with http-parser. // Typically there will be a normal HTTP server in front of us, proxying the // requests based on the URI. @@ -537,7 +537,7 @@ fcgi_muxer_push (struct fcgi_muxer *self, const void *data, size_t len) enum ws_handler_state { WS_HANDLER_CONNECTING, ///< Parsing HTTP - WS_HANDLER_OPEN, ///< Parsing WebSockets frames + WS_HANDLER_OPEN, ///< Parsing WebSocket frames WS_HANDLER_CLOSING, ///< Partial closure by us WS_HANDLER_FLUSHING, ///< Just waiting for client EOF WS_HANDLER_CLOSED ///< Dead, both sides closed @@ -1110,7 +1110,7 @@ ws_handler_finish_handshake (struct ws_handler *self) if (!connection || strcasecmp_ascii (connection, "Upgrade")) FAIL_HANDSHAKE (HTTP_400_BAD_REQUEST); - // Check if we can actually upgrade the protocol to WebSockets + // Check if we can actually upgrade the protocol to WebSocket const char *upgrade = str_map_find (&self->headers, "Upgrade"); struct http_protocol *offered_upgrades = NULL; bool can_upgrade = false; @@ -1286,7 +1286,7 @@ static struct simple_config_item g_config_table[] = { "bind_host", NULL, "Address of the server" }, { "port_fastcgi", "9000", "Port to bind for FastCGI" }, { "port_scgi", NULL, "Port to bind for SCGI" }, - { "port_ws", NULL, "Port to bind for WebSockets" }, + { "port_ws", NULL, "Port to bind for WebSocket" }, { "pid_file", NULL, "Full path for the PID file" }, // XXX: here belongs something like a web SPA that interfaces with us { "static_root", NULL, "The root for static content" }, @@ -2452,12 +2452,12 @@ client_scgi_create (EV_P_ int sock_fd) return &self->client; } -// --- WebSockets client handler ----------------------------------------------- +// --- WebSocket client handler ------------------------------------------------ struct client_ws { struct client client; ///< Parent class - struct ws_handler handler; ///< WebSockets connection handler + struct ws_handler handler; ///< WebSocket connection handler }; static bool -- cgit v1.2.3