on reusing HTTP as a spamd protocol

[Justin Mason <jm...@jmason.org>]

this RFC is worth reading -- http://www.faqs.org/rfcs/rfc3117.html ,
especially the discussion of IPP, which was built on top of HTTP:


  Mapping IPP onto HTTP 1.1 illustrates the former issue.  For example,
  the IPP server is supposed to signal its client when a job completes.
  Since the HTTP client must originate all requests and since the decision
  to close a persistent connection in HTTP is unilateral, the best that
  the IPP specification can do is specify this functionality in a
  non-deterministic fashion.

  Further, the IPP mapping onto HTTP shows that even subtle shifts in
  behavior have unintended consequences.  For example, requests in IPP are
  typically much larger than those seen by many HTTP server
  implementations -- resulting in oddities in many HTTP servers (e.g.,
  requests are sometimes silently truncated).  The lesson is that HTTP's
  framing mechanism is very rigid with respect to its view of the
  request/response model.


--j.