Standardize to "an HTTP".

README.rst

@@ -123,7 +123,7 @@ Why shouldn't I use ``websockets``?
 * If you're looking for a mixed HTTP / WebSocket library: ``websockets`` aims
   at being an excellent implementation of :rfc:`6455`: The WebSocket Protocol
   and :rfc:`7692`: Compression Extensions for WebSocket. Its support for HTTP
-  is minimal — just enough for a HTTP health check.
+  is minimal — just enough for an HTTP health check.
 
   If you want to do both in the same server, look at HTTP frameworks that
   build on top of ``websockets`` to support WebSocket connections, like

docs/faq/server.rst

@@ -295,15 +295,15 @@ You don't.
 HTTP and WebSocket have widely different operational characteristics. Running
 them with the same server becomes inconvenient when you scale.
 
-Providing a HTTP server is out of scope for websockets. It only aims at
+Providing an HTTP server is out of scope for websockets. It only aims at
 providing a WebSocket server.
 
 There's limited support for returning HTTP responses with the
 :attr:`~server.WebSocketServerProtocol.process_request` hook.
 
-If you need more, pick a HTTP server and run it separately.
+If you need more, pick an HTTP server and run it separately.
 
-Alternatively, pick a HTTP framework that builds on top of ``websockets`` to
+Alternatively, pick an HTTP framework that builds on top of ``websockets`` to
 support WebSocket connections, like Sanic_.
 
 .. _Sanic: https://sanicframework.org/en/

docs/howto/django.rst

@@ -10,7 +10,7 @@ WebSocket, you have two main options.
 
 2. Deploying a separate WebSocket server next to your Django project. This
    technique is well suited when you need to add a small set of real-time
-   features — maybe a notification service — to a HTTP application.
+   features — maybe a notification service — to an HTTP application.
 
 .. _Channels: https://channels.readthedocs.io/
 

docs/howto/sansio.rst

@@ -85,7 +85,7 @@ with :meth:`~server.ServerConnection.send_response`::
     response = connection.accept(request)
     connection.send_response(response)
 
-Alternatively, you may reject the WebSocket handshake and return a HTTP
+Alternatively, you may reject the WebSocket handshake and return an HTTP
 response with :meth:`~server.ServerConnection.reject`::
 
     response = connection.reject(status, explanation)

docs/intro/tutorial1.rst

@@ -163,7 +163,7 @@ page loads, draw the board:
       createBoard(board);
     });
 
-Open a shell, navigate to the directory containing these files, and start a
+Open a shell, navigate to the directory containing these files, and start an
 HTTP server:
 
 .. code-block:: console

docs/intro/tutorial2.rst

@@ -369,7 +369,7 @@ common pattern in servers that handle different clients.
     it in the URI because URIs end up in logs.
 
     For the purposes of this tutorial, both approaches are equivalent because
-    the join key comes from a HTTP URL. There isn't much at risk anyway!
+    the join key comes from an HTTP URL. There isn't much at risk anyway!
 
 Now you can restore the logic for playing moves and you'll have a fully
 functional two-player game.

docs/intro/tutorial3.rst

@@ -13,7 +13,7 @@ Part 3 - Deploy to the web
       web; you can play from any browser connected to the Internet.
 
 In the first and second parts of the tutorial, for local development, you ran
-a HTTP server on ``http://localhost:8000/`` with:
+an HTTP server on ``http://localhost:8000/`` with:
 
 .. code-block:: console
 

docs/reference/limitations.rst

@@ -13,7 +13,7 @@ right layer for enforcing this constraint. It's the caller's responsibility.
 
 .. _mandated by RFC 6455: https://www.rfc-editor.org/rfc/rfc6455.html#section-4.1
 
-The client doesn't support connecting through a HTTP proxy (`issue 364`_) or a
+The client doesn't support connecting through an HTTP proxy (`issue 364`_) or a
 SOCKS proxy (`issue 475`_).
 
 .. _issue 364: https://github.com/aaugustin/websockets/issues/364

docs/topics/authentication.rst

@@ -78,7 +78,7 @@ WebSocket server.
 3. **Setting a cookie on the domain of the WebSocket URI.**
 
    Cookies are undoubtedly the most common and hardened mechanism for sending
-   credentials from a web application to a server. In a HTTP application,
+   credentials from a web application to a server. In an HTTP application,
    credentials would be a session identifier or a serialized, signed session.
 
    Unfortunately, when the WebSocket server runs on a different domain from
@@ -208,7 +208,7 @@ opening the connection:
     // ...
 
 The server intercepts the HTTP request, extracts the token and authenticates
-the user. If authentication fails, it returns a HTTP 401:
+the user. If authentication fails, it returns an HTTP 401:
 
 .. code-block:: python
 
@@ -254,7 +254,7 @@ This sequence must be synchronized between the main window and the iframe.
 This involves several events. Look at the full implementation for details.
 
 The server intercepts the HTTP request, extracts the token and authenticates
-the user. If authentication fails, it returns a HTTP 401:
+the user. If authentication fails, it returns an HTTP 401:
 
 .. code-block:: python
 
@@ -295,7 +295,7 @@ Since HTTP Basic Auth is designed to accept a username and a password rather
 than a token, we send ``token`` as username and the token as password.
 
 The server intercepts the HTTP request, extracts the token and authenticates
-the user. If authentication fails, it returns a HTTP 401:
+the user. If authentication fails, it returns an HTTP 401:
 
 .. code-block:: python
 

docs/topics/design.rst

@@ -125,23 +125,23 @@ one another.
 
 On the client side, :meth:`~client.WebSocketClientProtocol.handshake`:
 
-- builds a HTTP request based on the ``uri`` and parameters passed to
+- builds an HTTP request based on the ``uri`` and parameters passed to
   :meth:`~client.connect`;
 - writes the HTTP request to the network;
-- reads a HTTP response from the network;
+- reads an HTTP response from the network;
 - checks the HTTP response, validates ``extensions`` and ``subprotocol``, and
   configures the protocol accordingly;
 - moves to the ``OPEN`` state.
 
 On the server side, :meth:`~server.WebSocketServerProtocol.handshake`:
 
-- reads a HTTP request from the network;
+- reads an HTTP request from the network;
 - calls :meth:`~server.WebSocketServerProtocol.process_request` which may
-  abort the WebSocket handshake and return a HTTP response instead; this
+  abort the WebSocket handshake and return an HTTP response instead; this
   hook only makes sense on the server side;
 - checks the HTTP request, negotiates ``extensions`` and ``subprotocol``, and
   configures the protocol accordingly;
-- builds a HTTP response based on the above and parameters passed to
+- builds an HTTP response based on the above and parameters passed to
   :meth:`~server.serve`;
 - writes the HTTP response to the network;
 - moves to the ``OPEN`` state;

docs/topics/logging.rst

@@ -104,7 +104,7 @@ can set ``logger`` to a :class:`~logging.LoggerAdapter` that enriches logs.
 For example, if the server is behind a reverse
 proxy, :attr:`~legacy.protocol.WebSocketCommonProtocol.remote_address` gives
 the IP address of the proxy, which isn't useful. IP addresses of clients are
-provided in a HTTP header set by the proxy.
+provided in an HTTP header set by the proxy.
 
 Here's how to include them in logs, assuming they're in the
 ``X-Forwarded-For`` header::

src/websockets/exceptions.py

@@ -176,7 +176,7 @@ class InvalidMessage(InvalidHandshake):
 
 class InvalidHeader(InvalidHandshake):
     """
-    Raised when a HTTP header doesn't have a valid format or value.
+    Raised when an HTTP header doesn't have a valid format or value.
 
     """
 
@@ -195,7 +195,7 @@ def __str__(self) -> str:
 
 class InvalidHeaderFormat(InvalidHeader):
     """
-    Raised when a HTTP header cannot be parsed.
+    Raised when an HTTP header cannot be parsed.
 
     The format of the header doesn't match the grammar for that header.
 
@@ -207,7 +207,7 @@ def __init__(self, name: str, error: str, header: str, pos: int) -> None:
 
 class InvalidHeaderValue(InvalidHeader):
     """
-    Raised when a HTTP header has a wrong value.
+    Raised when an HTTP header has a wrong value.
 
     The format of the header is correct but a value isn't acceptable.
 
@@ -315,7 +315,7 @@ def __str__(self) -> str:
 
 class AbortHandshake(InvalidHandshake):
     """
-    Raised to abort the handshake on purpose and return a HTTP response.
+    Raised to abort the handshake on purpose and return an HTTP response.
 
     This exception is an implementation detail.
 

src/websockets/legacy/auth.py

@@ -67,7 +67,7 @@ async def check_credentials(self, username: str, password: str) -> bool:
 
         Returns:
             bool: :obj:`True` if the handshake should continue;
-            :obj:`False` if it should fail with a HTTP 401 error.
+            :obj:`False` if it should fail with an HTTP 401 error.
 
         """
         if self._check_credentials is not None:
@@ -81,7 +81,7 @@ async def process_request(
         request_headers: Headers,
     ) -> Optional[HTTPResponse]:
         """
-        Check HTTP Basic Auth and return a HTTP 401 response if needed.
+        Check HTTP Basic Auth and return an HTTP 401 response if needed.
 
         """
         try:

src/websockets/legacy/server.py

@@ -329,9 +329,9 @@ async def process_request(
         You may override this method in a :class:`WebSocketServerProtocol`
         subclass, for example:
 
-        * to return a HTTP 200 OK response on a given path; then a load
+        * to return an HTTP 200 OK response on a given path; then a load
           balancer can use this path for a health check;
-        * to authenticate the request and return a HTTP 401 Unauthorized or a
+        * to authenticate the request and return an HTTP 401 Unauthorized or an
           HTTP 403 Forbidden when authentication fails.
 
         You may also override this method with the ``process_request``
@@ -776,7 +776,7 @@ async def _close(self, close_connections: bool) -> None:
 
         if close_connections:
             # Close OPEN connections with status code 1001. Since the server was
-            # closed, handshake() closes OPENING connections with a HTTP 503
+            # closed, handshake() closes OPENING connections with an HTTP 503
             # error. Wait until all connections are closed.
 
             close_tasks = [

tests/legacy/test_client_server.py

@@ -727,7 +727,7 @@ def test_protocol_custom_server_header(self):
 
     @with_server(create_protocol=HealthCheckServerProtocol)
     def test_http_request_http_endpoint(self):
-        # Making a HTTP request to a HTTP endpoint succeeds.
+        # Making an HTTP request to an HTTP endpoint succeeds.
         response = self.loop.run_until_complete(self.make_http_request("/__health__/"))
 
         with contextlib.closing(response):
@@ -736,7 +736,7 @@ def test_http_request_http_endpoint(self):
 
     @with_server(create_protocol=HealthCheckServerProtocol)
     def test_http_request_ws_endpoint(self):
-        # Making a HTTP request to a WS endpoint fails.
+        # Making an HTTP request to a WS endpoint fails.
         with self.assertRaises(urllib.error.HTTPError) as raised:
             self.loop.run_until_complete(self.make_http_request())
 
@@ -745,7 +745,7 @@ def test_http_request_ws_endpoint(self):
 
     @with_server(create_protocol=HealthCheckServerProtocol)
     def test_ws_connection_http_endpoint(self):
-        # Making a WS connection to a HTTP endpoint fails.
+        # Making a WS connection to an HTTP endpoint fails.
         with self.assertRaises(InvalidStatusCode) as raised:
             self.start_client("/__health__/")