WebSocket control frames are automagically responded to. Iff there's an active read(). Basically, having an active read() at almost all times is a requirement of any correct program using Beast. Even though I enjoy the help from the library, and the requirement is usually met, I found this specific behaviour to be inconsequent. What's the call to action? What change is being proposed? I don't have a concrete proposal. What I was trying to describe is the discrepancy between the general look and feel of the library - where the user is in full control, and hence bears full responsibility - and the automagic happening with WebSocket control frames. And, to make it feel even more awkward, the automagic is actually semi-automatic. I realize
"out of scope": that dreaded phrase that no one wants to hear :)
The features you described are arbitrary. Why forms and not basic authentication? Why URL decoding but not a full URI parser? Why a full URI parser but no handling for redirects? What about supporting proxies? Anything that I add is going to satisfy some users and disappoint others. I don't agree. Any feature you add will satisfy some users, and not-yet-satisfy others. Big difference. That doesn't mean that I won't be building new higher level features (I'm already working on a URL decoder) but I think they belong in a separate library with its own documentation, tests, CI infrastructure, and also separate Boost formal review process. Still, there's only so much I can do - HTTP is a MASSIVE domain!. The only reason I was able to get Beast to where it is at was by being strict on what features I would support. For a new library, the expectations would be very high. It would have to support all of HTTP - which may well mean that such a swiss army knife
On 07/05/2017 04:13 PM, Vinnie Falco wrote: there's probably no sane way to have control frames always responded to during the lifetime of a websocket::stream. It may, however, be reasonable to give control back to the user and just provide convenient utilities for sending the appropriate responses. library will never happen. For an existing library, like Beast, the level of expectation (concerning new features) is a lot more bearable. Anything you give us will be seen as a goodie. Beast CAN add an URI parser without supporting Basic Authentification. Or Basic Auth without supporting form data at the same time. You could also put the functionality into a utility namespace and exclude that from your standards proposal.