Backporting rlm_rest to 2.1.x

[Arran Cudbard-Bell]

On 11 Aug 2012, at 10:27, Gavin Alves <gavin.alves at gmail.com> wrote:

> Thanks Alan.  Pretty much the answer I was expecting but not the one I was hoping for.
> 
> 3.0 is not mature enough for my requirements, especially as you say there are significant architectural changes.

You know rlm_rest has (to my knowledge) never been used in a production environment right? :)

> 
> I've decided to try initiating the http requests using rlm_perl, which as I understand it, should have no significant overhead insofar as the interpreter is concerned.  

Shouldn't do.

> The only downside I see is that it will not be possible to reuse the curl connections.  However this is compensated for by the ability to design requests in a high level language.
> 
> Please shoot me down if this is a terrible idea.
> 

If you can stand the overhead of TCP connection setup and tear down for *every* request, then it's ok. It depends entirely on your load and acceptable latencies. It's the difference between a 2+ packet exchange and a 7+ packet exchange. If your HTTP server is local to the machine or on your LAN then it'll probably be fine, if it's on some corporate server 50ms away, then i'd strongly advise against it.

(as you've seen) rlm_rest takes advantage of CURL's connection caching feature. The module itself caches the handles, and CURL uses persistent TCP connections (with HTTP/1.1) to avoid the overhead of re-establishing the TCP connection every request.

Anyway. rlm_rest uses API features that are only available in 3.0. Nested configuration parsing isn't there in 2.0, nor is the connection pool API, there were also changes to xlat.c for printing escaped values in URL format and JSON, and something to parse list qualifiers in attribute names. Digging out all the core code and backporting it would be a PITA.

Unless you're willing to do it yourself or contract someone to do it, it ain't going to happen.

-Arran