From jeroenoom@ @end|ng |rom gm@||@com  Thu Dec  5 16:45:57 2024
From: jeroenoom@ @end|ng |rom gm@||@com (Jeroen Ooms)
Date: Thu, 5 Dec 2024 16:45:57 +0100
Subject: [Rd] Exposing native httpd server
In-Reply-To: <a7cada24-51e9-4e48-8977-07b913fb40ff@gmail.com>
References: <a7cada24-51e9-4e48-8977-07b913fb40ff@gmail.com>
Message-ID: <CABFfbXvH10FXV6eoLciKA-GETjQn5TE_uj2kgxWMvAyr7-hG8A@mail.gmail.com>

On Thu, Dec 5, 2024 at 2:43?AM Ji?? Moravec <jiri.c.moravec at gmail.com> wrote:
>
> R has a native HTTP server that is used for serving R help pages
> interactively, at least on the loopback device (127.0.0.1)
>
> But all of the working are internal, not exposed to user and not documented.

This has been available for a long time. The 'webutils' package has
basic examples of how to handle and parse http requests in R using
either using Rhttpd or httpuv:

   webutils::demo_rhttpd()
   webutils::demo_httpuv()

You can adapt from here to your needs. R provides all the hooks you
need, I think you'll find little appetite for duplicating more web
server tooling into base R.





> This is quite shame since the server seems to be fully capable of
> handling basic tasks,
> be it serving static websites or even interactively processing queries.
>
> This was previously noticed by Jeffry Horner, the author of the Rook
> package.
> I am just a guy who found it interesting.
>
> The basic working is as follows:
> User needs to either overwrite the internal `tools:::httpd` function or
> add their hook into the internal environment tools:::.httpd.handlers.env.
>
> In the former case, the user will be of a full control of the server, in
> the later case, the `app` will be hooked to `/custom/app` instead.
> All that is needed then is to run the interactive help that starts the
> webserver.
>
> Based on the breadcrumbs left on the way, I was able to write a server
> that emulates much more complex `servr` package that I have previously
> used to test locally my blog.
>
> https://gist.github.com/J-Moravec/497d71f4a4b7a204235d093b3fa69cc3
>
> You can see that I am forced to do some illegal procedures:
>   * tools:::httpd needs to be replaced
>   * the server doesn't have knowledge of a directory so setwd needs to
> be set
>   * the function must not end, otherwise the directory is changed during
> the server lifetime (and depends on the current working directory)
>
> I would like to suggest and probe for willingness to expose the native
> http server.
> This would include:
>
> * de-hardcoding the server so that we can register other functions not
> just httpd
> * exporting many functions and renaming them (such as mime_type)
> * writing better interfaces, `startDynamicHelp` is kind of hard to work
> with, something like httpd_start(dir, fun, port), httpd_stop(port) and
> httpd_status(port) would be much cleaner.
>
> I would like to say that I have no idea what I am doing, I don't
> understand webtech or the internal implementation, so if there are
> reasons why this isn't a great idea...
>
> I am happy to make a PR for the R part.
> https://github.com/wch/r-source/blob/trunk/src/library/tools/R/dynamicHelp.R
> The C part with the R's C internals look to me like a black magic and I
> don't feel confident enough.
> https://github.com/wch/r-source/blob/trunk/src/modules/internet/Rhttpd.c
>
> See this old stackoverflow answer, where someone was looking for `python
> -m SimpleHTTPServer 8080`
>
> https://stackoverflow.com/q/12636764/4868692
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] Exposing native httpd server
Jeroen Ooms