'''[http://tools.ietf.org/html/rfc2616%|%Hypertext Transfer Protocol]''', or
'''HTTP''',  is the protocol used within the [WWW%|%World Wide Web] for
transferring documents. Its latest version is [HTTP 1.1%|%1.1]. [HTTP/2], an
incompatible binary protocol, is designed to be its successor.



** See Also **

   
   [http://www.w3c.org/Protocols/%|%HTTP - Hypertext Transfer Protocol]:   The official page for the HTTP protocol specification.



** Description **

HTTP was preceded by [Tuplespace], which is data-centric rather than
resource-centric, and provides an even smaller set of verbs.

[EMJ] 2015-11-13 : Is someone claiming an actual connection here? If not,
why mention one particular idea among many about how to share data across a network?

[PYK] 2015-11-13: Thanks for the heads-up.  I had inadvertantly placed this
note on the [HTML] page, and have now moved it over to this page.
HTTP must have been inspired by tuplespace, which is an earlier invention of a
restricted set of verbs that is sufficient for the purpose distributing data
among peers.  HTTP is very similar, with only a few more verbs and a switch in
focus from data to resources.  People considering an HTTP-based architecture
like [REST] might be interested in considering tuplespace as an alternative.
Tuplespace is more transactional.  It provides an atomic `pop` operation, while
HTTP doesn't.  I find it interesting that [REST] in some ways is an attempt at
retrofitting HTTP to be more like Tuplespace, somewhat like [Javascript] has
managed to retrofit [HTML] to be more of a traditional desktop user interface
system. HTTP and HTML were designed for a rather narrow purpose, and because of
their wild success have ended up evolving back toward systems the predate them.
 


** Servers **

   [Web Publishing]:   contains a list of HTTP servers




** Tcl Clients **

   [http]:   A client-side implementation of HTTP bundled with [Tcl].

   [nstcl-http]:   Another client-side implementation of HTTP.

   [rl_http]:   A [REpresentational State Transfer, REST%|%REST]-capable, never-blocking HTTP client package that supports HTTPS, deflate, chunked encoding for Tcl, [NaviServer], or [AOLserver].

   `[ycl comm http]`:   An [Hypertext Transfer Protocol%|%HTTP] client that uses [coroutine%|%coroutines] and [reflected channel%|%reflected channels].  Supports chunked encoding.

(The [https://github.com/efrecon/docker-client%|%Docker client] implementation includes an implementation of the minimal subset of HTTP necessary for the very purpose of talking to the Docker daemon.  It has the particularity (over [http]) to support chunked encoding, and I wish I had known about [rl_http] before! Note that the implementation is also able to perform HTTP protocol operation on top of any file descriptor, since it uses pipes to `netcat` or `nc` to talk to local Docker daemons (UNIX domain sockets). [EF])



** Tools **

   [autoproxy]:   a [tcllib] module that attempts to automate the use of HTTP proxy servers in Tcl HTTP client code.

   [vfs::http]:   a [VFS%|%virtual filesystem] for HTTP transactions 



** See Also **

   [http in Jacl]:   

   [Tunnel HTTP through SMTP]:   

   [Tunnel IRC through HTTP proxies]:   allow HTTP/1.1 CONNECTs to the outside.


** Line Translation **

[PYK] 2016-04-13:  When forming an HTTP request in Tcl, make sure lines end in
CRLF.  Otherwise, the reponse may be `400 Bad Request`.  The [Tcllib
MIME%|%MIME] module in [Tcllib] produces messages with CRLF as the line
delimiter, in which case the channel should be configured as `-translation
binary`.




<<categories>> Internet | protocol