Secure websocket using example code unable to handle unsecured requests

[davidawesome02]

Versions:
websockets 12.0
Python 3.10.13

On the examples (readthedocs, github) the server is able to connect via https; but any attempts to connect via http no longer connect, only immediate closing the server.

While testing with (not exact code from demo, but should be close enough to be the same)

async def process_request_ws(path_unprocessed: str, request_headers):
    print(path_unprocessed)

# start code
ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ssl_context.load_cert_chain(certfile="localhost.pem", keyfile="key.pem")
async with websockets.serve(hello, "0.0.0.0", 8000, ssl=ssl_context,process_request=process_request_ws):

No path is printed while using this, and all browsers just return ERR_EMPTY_RESPONSE

keys generated with openssl req -x509 -newkey rsa:4096 -keyout key.pem -out localhost.pem -sha256 -days 3650 -nodes -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname" -subj '/CN=localhost'

[davidawesome02]

New note:
ssl python seams to have security concerns, but not sure if it effects servers, seams to be a client only thing, and not sure if ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER) is good enough

also:
the code that handles the ssl stuff seams to just wrap it, and this may not allow for the use of non tls specification after the fact.... could we read off the first bit of the request and actualy check if it wants to be tls instead of raw tcp?

may be a wrong lead, but just was goin through code quickly

[aaugustin]

Indeed, websockets cannot handle TLS and non-TLS connections on the same port.

websockets usually runs behind a routing layer (which every cloud hosting service provides) or a reverse proxy that takes care of terminating TLS connections — and responding to non-TLS connection appropriately.

What's your use case for supporting both?

[davidawesome02]

Indeed, websockets cannot handle TLS and non-TLS connections on the same port.

websockets usually runs behind a routing layer (which every cloud hosting service provides) or a reverse proxy that takes care of terminating TLS connections — and responding to non-TLS connection appropriately.

What's your use case for supporting both?

I just assumed it would be supported, I just wanted to attempt to run without a reverse proxy on the output, but should it be required to keep the same python context, I can continue with that route.

Is there any possibility to run this with both tls and non tls; It seams to be a arbitrary requirement, should we not attempt to fix it for any reason? Is it intentional, or not?

[aaugustin]

This behavior is inherited from create_server.