jchampio/apache-websocket

WebSocket plugin module for the Apache HTTP Server

apache-websocket's Issues

Make plugins choose subprotocols by index instead of providing a string

mod_websocket_protocol_set() takes a const char* as an argument. This implies that it is legal for plugins to provide any string as a subprotocol, when in fact they must choose a subprotocol from the list provided by the client (or use none at all). The API should change to accept a numerical index (pointing to a subprotocol in the connection's protocols array) rather than any arbitrary string.

Allow plugins to write to the server log

Plugins should be able to write to the server log through the WebSocketServer * without having to write through a magic request_rec *.

Allow plugins to stream messages frame-by-frame

Certain applications may benefit from the ability to stream WebSocket frames, both incoming and outgoing. The current API allows only message-level communication.

Allow plugins to read Pong bodies

RFC 6455 allows endpoints to send application data in pings. If we don't let the plugin read the application data received in the pong, this feature is somewhat useless.

Upgrade tests hang with Twisted 16.6 and later

t.w.c.Agent now completely ignores 1xx responses. See twisted/twisted#583.

Let developers point the test suite at an arbitrary server

The test suite currently hardcodes ws://127.0.0.1 as its root for constructing test URLs. It should be possible for developers to point the test suite at any arbitrary scheme/hostname/port, both as a general usability improvement and to assist in the testing of TLS-enabled installations (wss://).

mod_websocket chooses the first client subprotocol by default

If a plugin doesn't manually set a subprotocol in its on_connect callback, mod_websocket will just choose the first one provided by the client. This means that unsuspecting plugins may be "agreeing" to speak a subprotocol that they know nothing about. This behavior should be removed.

Python 2 is dead; move to Python 3

The tests are written in Python 2/Twisted 16.5. They need a update, and a possible port to Python 3's native async support, since modern versions of Twisted no longer support our t.w.c.Agent use case.

Autobahn|TestSuite might hinder movement here; the documentation as of now still claims that only Python 2 is supported.

Support per-message compression (RFC 7692)

https://tools.ietf.org/html/rfc7692

Pass the Autobahn Test Suite

It should be possible for clients to create a module that can pass the Autobahn test suite.

This issue should gate any "1.0" release.

Allow other httpd modules to implement WebSocketHandlers

The architecture is currently a hub/spoke plugin model, but other server modules should be able to implement their own handlers using the same API.

Use mod_grpcbackend as the driving use case. #32 is one implementation, using an OPTIONAL_HOOK; is there another hook option that makes clients' lives easier?

mod_websocket rails CPU (httpd 2.4.16, Ubuntu 14.04)

Open up a connection (i.e. through the sample echo page) and watch top. Not sure when this was introduced; I don't remember seeing it in the 2.4.10-ish timeframe.

Allow plugins to read and write close codes/reasons

Plugins currently cannot read or write the status code or reason string for close frames. Incoming close frames are completely hidden by the module, and server->close() does not take any code or reason string in its parameter list.

Consider switching to the new ap_hook_protocol_propose/switch architecture

httpd 2.4.17 added experimental hooks for automatically handling Upgrade requests (for HTTP/2), which might greatly simplify the module handshake code. Even if it doesn't work out, getting feedback upstream to the mod_http2 devs would be appreciated.

Current requirements.txt is outdated

With upstream changes to autobahntestsuite, it appears that the current requirements.txt no longer works correctly -- several pip modules are either missing or incorrect. See also crossbario/autobahn-testsuite#55.

mod_websocket interacts poorly with mod_reqtimeout

mod_reqtimeout (predictably) causes WebSocket connections to close before we want them to. Perhaps there is a way to tell mod_reqtimeout not to worry about a certain connection?

server->send() cannot indicate failure if sending an empty message

If a plugin sends an empty (zero-length) message, the return code of 0 ("zero bytes written") is indistinguishable from failure.

Several invalid handshakes are not rejected

mod_websocket is too lax in its parsing of the initial client handshake (i.e. it doesn't correctly implement Sec. 4.2.1 of the RFC). Some examples:

• Sec-WebSocket-Version values such as 13abc, +13, and 08 are allowed
• HEAD requests are upgraded
• the Origin header isn't checked at all
• any value is accepted for Sec-WebSocket-Key

Provide a "allow reserved close codes" option

Per this conversation with Tobias Oberstein: WebSocket plugin developers and server admins should have a switch which allows reserved+undefined opcodes in the range 1000-2999. This would allow developers to research new official extensions to the protocol.

This switch should default to "off", since most end users of the module will not be doing official development work on RFCs. Additionally, reserved opcodes that are defined as "MUST NOT be set as a status code" should continue to be rejected even if this mode is turned on.

Poor performance when receiving fragmented messages

Incoming frames are concatenated into a single contiguous block of memory, which is realloc'd once for every single frame. This craters performance for extremely fragmented messages (see for example Autobahn|TestSuite case 9.3.1).

Look into minimizing the number of reallocations that must be done (maybe keep a linked list of frames and concatenate once at the end?).

Non-conformant close frame handling

Autobahn flags a few issues in the way we handle close frames:

• Close frame payloads with only one byte are not rejected (it has to either be empty or at least a two-byte status code)
• Invalid UTF-8 close frame payloads are not rejected
• Invalid close status codes are not rejected

Can we get rid of the draft-76 implementation?

It's really old.

MaxMessageSize applies only to frames, not messages

The MaxMessageSize directive only rejects frames that are longer than the payload_limit. If an adversary sends a huge number of frames that are smaller than the MaxMessageSize, the module will happily try to buffer all of them.

Side note: why is MaxMessageSize not named WebSocketMaxMessageSize?

Failing Python tests often result in a hang

A test that fails to conform to expectations usually results in a hang (since the test will end up waiting for an event that never actually occurs). This is annoying when debugging issues.

The test suite framework should be modified to understand the concept of a timeout.

Change MaxMessageSize to WebSocketMaxMessageSize

The MaxMessageSize directive should be renamed to match the rest of the module's directives, which all start with the WebSocket... prefix.

One WebSocket connection monopolizes an entire Apache worker thread

The current threading architecture blocks an entire worker thread for the duration of a WebSocket connection. This means that once a certain number of WebSocket connections are established, the server will be completely unable to serve new requests.

We need some way to either change the architecture so that idle workers can be released back to the server, or provide a limit on the number of simultaneous WebSocket connections that can be made to the server, in order to avoid this denial-of-service situation.

Allow plugins to receive configuration settings

This would allow plugins to be configured via the main server configuration file.

Use of ap_get_conn_socket() breaks in Apache 2.2

Turns out ap_get_conn_socket is Apache 2.4 only. The "2.2 way" is to use

ap_get_core_module_config(state->r->connection->conn_config);

but it seems like that function isn't exported publicly...

No Origin checks are done on incoming handshakes

The Origin header (or Sec-WebSocket-Origin, for earlier draft versions) is never checked during the opening handshake, which means the server does not reject unauthorized cross-origin connections.

apr_int64_t is everywhere; length types need to be fixed

apr_int64_t is used almost everywhere. Sometimes it's not needed (i.e. the WebSocket protocol version), sometimes an apr_size_t should be there instead (i.e. when calculating buffer sizes), and sometimes we should probably use apr_uint64_t because negative values are unnecessary.

Remove obsolete directives

...such as MaxMessageSize. Obviously this will require a version bump.