Incompatible with Werkzueg>=2.0

[rmorshea]

I'm experiencing werkzeug.routing.WebsocketMismatch: 400 Bad Request after the recent release of werkzueg and flask. I'm not really sure why this is, but the docs state:

you receive a WebsocketMismatch exception if the only match is a WebSocket rule but the bind is an HTTP request, or if the match is an HTTP rule but the bind is a WebSocket request.

Here's the traceback I'm observing:

Traceback (most recent call last):
  File "/venv/lib/python3.9/site-packages/gevent/pywsgi.py", line 999, in handle_one_response
    self.run_application()
  File "/venv/lib/python3.9/site-packages/geventwebsocket/handler.py", line 75, in run_application
    self.run_websocket()
  File "/venv/lib/python3.9/site-packages/geventwebsocket/handler.py", line 52, in run_websocket
    list(self.application(self.environ, lambda s, h, e=None: []))
  File "/venv/lib/python3.9/site-packages/flask/app.py", line 2464, in __call__
    return self.wsgi_app(environ, start_response)
  File "/venv/lib/python3.9/site-packages/flask_sockets.py", line 40, in __call__
    handler, values = adapter.match()
  File "/venv/lib/python3.9/site-packages/werkzeug/routing.py", line 2026, in match
    raise WebsocketMismatch()

[rmorshea]

I think this may be a knock on effect of #80

[rmorshea]

Never mind. I think this is distinct.

[sphaero]

Had the same issue. Fixed it by forcing the flask version to 1.1.4. There was a Flask major release (2.0.0) just a few days ago.

[rmorshea]

Yup that was my solution too. You should be able to do the more generic flask<2.0 though.

[dbermuehler]

@tomviner provided a fix for this issue with his pull request #82. Will this one be merged soon to master to fix the issue or are there any obstacles?

[atzannes]

seems like it would help a lot of people to have a release of flask-sockets where its Flask dependency is constrained to flask<2.0

[rmorshea]

I how that would play with pip's new resolver. Would it backtrack to a version that supported flask>=2.0, thus negating the benefits of the constrained release of flask-sockets?

[atzannes]

Never mind. I think this is distinct.

By the way, it is distinct but technically flask-sockets depends on flask which in turn depends on werkzeug (in other words flask-sockets does not depend directly on werkzeug), which is why the title and the body of this issue are a bit incongruous.

I how that would play with pip's new resolver. Would it backtrack to a version that supported flask>=2.0, thus negating the benefits of the constrained release of flask-sockets?

Very good question. I thought a lot about how to answer. Here's the short version. I could be wrong but I'm pretty sure it will work properly because the depends-on constraints define a directed acyclic graph with the root of the graph being the package that's the argument of pip install. This means that there is a complexity advantage for the constraint resolution problem of finding compatible versions for the dependencies to start with packages that are closer to the root of the graph, and because flask-sockets depends on flask it will always be closer to the root than flask for a reasonable definition of distance.

A perhaps more intuitive way to reach the same conclusion is that flask-sockets contains information on what it wants out of flask (whereas flask places no constraints on flask-sockets), and pip must download a version of a package to figure out what its dependencies and dependency constraints are, which is expensive in time, space, and bandwidth. So, it is much more advantageous for pip to "backtrack" on the flask version than on the flask-sockets version.

An example of the same problem and its solution can be seen in flask itself. Flask depends on werkzeug and when werkzeug==2.0.0 came out, it had backwards incompatible changes. At the time Flask=1.1.2 was current and required werkzeug>0.15 (here), so they released Flask==2.0.0 which requires werkzeug>=2.0 (here) and Flask==1.1.3 which requires werkzeug >0.15, <2.0 (here).

I think doing something similar here is probably the right thing, especially as it sounds there is a concern PR #82 might result in incoherent behavior when paired with werkzeug < 2 (i.e., Flask < 2.0). Specifically, I think the smoothest way forward is:

• having a new release flask-sockets==0.2.2 that just adds the requirement for Flask<2.0
• having a new release flask-sockets=2.0.0 (to match the major version of Flask, or 0.3.0 if we don't like that idea) which will include PR Set websocket=True for Rule, fixes #81 #82 and which will also require Flask>2.0.

[tomviner]

Thanks @atzannes this sounds well thought out to me.