Hello there, Been playing around with rlm_rest, and it works like a charm over HTTPS... until you activate HTTP/2 on your web server. Because then I get this in the logs: (1) rest: Processing response header (1) rest: ERROR: Malformed HTTP header: Status line too short (1) rest: ERROR: Received 13 bytes of response data: HTTP/2 404 (1) rest: ERROR: Request failed: 23 - Failed writing received data to disk/application (1) rest: ERROR: Server returned no data rlm_rest (rest): Released connection (0) Note that performing the HTTP call with cURL works with both HTTP/1.1 and HTTP/2 (correct answer given when trying to authenticate a user) so the web server behavior in itself is not the cause. It seems that rlm_rest does not handle HTTP/2 very well, expecting something that does not exist under this protocol, or at least before the parties agreed to use it. I'm no HTTP/2 expert, but cURL in verbose mode shows: * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 ... 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? Thanks! Hoggins!
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). -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
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
On Jul 30, 2019, at 6:30 AM, Hoggins! <hoggins@wheres5.com> wrote:
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:
The rlm_rest module also has to support HTTP/2. Right now, it expects an HTTP/1.1 (or earlier) response. The HTTP/2 protocol changes nearly everything about the protocol. So the explicit checks for HTTP/1.1 return codes in rlm_rest just won't with with 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).
Yes.
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.
HTTP/2 has to be explicitly supported in rlm_rest. For now, it's best to just disable HTTP2 in the rlm_rest module. Alan DeKok.
On 30 Jul 2019, at 23:12, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 30, 2019, at 6:30 AM, Hoggins! <hoggins@wheres5.com> wrote: 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:
The rlm_rest module also has to support HTTP/2. Right now, it expects an HTTP/1.1 (or earlier) response.
The HTTP/2 protocol changes nearly everything about the protocol. So the explicit checks for HTTP/1.1 return codes in rlm_rest just won't with with 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).
Yes.
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.
HTTP/2 has to be explicitly supported in rlm_rest.
For now, it's best to just disable HTTP2 in the rlm_rest module.
HTTP/2 works fine and has been tested in master branch. Parse fixes just need backporting if we want to support this in v3. -Arran
On Jul 30, 2019, at 11:13 AM, Hoggins! <hoggins@wheres5.com> wrote:
Le 30/07/2019 à 16:12, Alan DeKok a écrit :
For now, it's best to just disable HTTP2 in the rlm_rest module.
How can I achieve this?
Source code patches. Or, back-port the HTTP/2 fixes from the "master" branch. Alan DeKok.
Oh right. I thought I could do that with some config. As I'm using FreeRADIUS pre-packaged (I used to compile it from source, but then I took an arrow... well), I'll find another way around... by disabling HTTP/2 on server side for this specific client ! Thanks ! Hoggins! Le 30/07/2019 à 20:33, Alan DeKok a écrit :
For now, it's best to just disable HTTP2 in the rlm_rest module. How can I achieve this? Source code patches.
Or, back-port the HTTP/2 fixes from the "master" branch.
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
brent s. -
Hoggins!