The documentation for the HTTP server libraries has use_module(library(http/http_server)) but the documentation for Threaded HTTP Server says that http/thread_httpd “defines the HTTP server frontend of choice”.
Are the references to http/http_server merely left-overs, or are there reasons for sometimes preferring it? (E.g., perhaps it’s better for debugging?)
(People don’t necessarily follow the organization of the documentation; I tend to use Google search to find things, so I sometimes read the documentation from back to front. This, of course, is my fault; so feel free to ignore my comments about how the documentation is organized.)
No. In fact, http/http_server is a more recent library that merely combines the typical HTTP libraries just about any server needs. The idea of a common request handling system and three controlling libraries is outdated, the threaded server now being the only sensible controlling library.
So, new code should use http/http_server, unless you want some special setup that requires you to replace one of the components. In that case you can still profit from the modular design.
Is it correct to infer that http_files:http_reply_from_file should be replaced by http_dispatch:http_reply_file because the former doesn’t appear in the export list from http/http_server?
I assume you refer to http_reply_from_files (with s)? That is not part of the http_server library. Perhaps it should be, but it comes with stuff such as icons to reply directory indexes and thus it isn’t nicely minimal. Replying files is also not really the primary point of the SWI-Prolog server. For example, nginx does this better
If you need it, just add
:- use_module(library(http/http_files)).
The idea behind the http_server library is that it has an easier to remember name, avoids the need for including about 5 files to get a basic server and hides all the internal and deprecated interfaces. If you need more than the real basics you have to add additional libraries (e.g., the above, sessions, authentication, etc.)
http_reply_from_files/3 (with an “s”) seems to be a more general wrapper on http_reply_file/3, which is why I’m surprised that the latter is exported from http/http_server.
I’ll try to make a PR with some suggested changes to the http documentation …
I fear these things always remain a bit arbitrary. The reasoning is partly technical, as in http_reply_file/3 is part of the http_dispatch library, which is part of the server wrapper. It is also pretty generic and basic functionality. http_reply_from_files/3 is in a different library, does a lot of stuff you may (not) want and has dependencies on (icon) files that make deployment of runtime systems more complicated.
So, I think leaving it out of the core makes some sense, but if it is widely felt it should be in I can accept that as well. After all, many servers require it if they implement a web server aiming at the browser to serve CSS and javaScript. But … API servers (JSON I/O) typically do not need it and that might be an important application area for (SWI-)Prolog. I have little clue how many HTTP servers have been written in SWI-Prolog and what they do …
