Yes ! Le 30/07/2019 à 11:24, brent s. a écrit :
On 7/30/19 4:45 AM, Hoggins! wrote:
Hello there, (SNIP) ... which seem to indicate that some connection upgrade is being performed (like for a websocket?), and one might think that rlm_rest does not like it very much.
Are these assumptions correct?
Yep!
https://http2.github.io/http2-spec/
Specifically worth noting, https://http2.github.io/http2-spec/#HttpSequence
It's *supposed* to be fully backwards-compatible with HTTP/1.1 if a client doesn't support HTTP/2. It sounds like when you're enabling HTTP/2 in your webserver, it's *forcing* http/2. IIRC, however, HTTP/2 support is *announced* by the client, and THEN the server should upgrade to HTTP/2 (if supported).
Indeed with cURL, this what I see: * ALPN, offering h2 * ALPN, offering http/1.1 (SNIP) * ALPN, server accepted to use h2 So cURL sends to the server that it supports HTTP/2. What is surprising is that at startup, FreeRadius says that the rlm_rest module is compiled against a libcurl version that seems to fully support HTTP/2: Info: rlm_rest: libcurl version: libcurl/7.65.3 OpenSSL/1.1.1c-fips zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.0.5) libssh/0.9.0/openssl/zlib nghttp2/1.38.0 The things is that in rlm_rest/rest.c (https://doc.freeradius.org/rest_8c_source.html), it seems that rlm_rest only expects HTTP/1.1 and nothing else (line 1572). I don't know if it's relevant to have a more "relaxed" control of what protocol a server answers with, or if HTTP/2 should be explicitly supported in the code.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html