Known bugs/warts to fix
-----------------------
* Needs to be possible to register new auth types with soup-auth.c

* SoupAuthDigest/SoupServerAuthDigest don't support qop="auth-int"

* We don't handle trailers in chunked responses


HTTP Features
-------------

* Handle gzip Content-Encoding

* Handle cookies (RFC 2109) via a SoupCookieJar message filter
	* RFC 2965 supposedly obsoletes 2109, but I don't think
	  anyone uses it

* Handle caching, also via SoupMessageFilter
	* rcd has some of the logic for this already

* NTLM Proxy-Authentication support, GSS-Negotiate support

* Pipelining


SOAP/XML-RPC Features
---------------------

* Add XML-RPC support (bug-buddy wants this)

* Bring back WSDL compiler from old soup module?

* The current SoupSoapMessage/Response API doesn't really make life a
  whole lot easier for the user... You have to marshall the data in
  exactly the right order anyway, so you might as well just be
  g_string_appending...


Misc Features
-------------

* Bring back SOCKS support?

* Bring back CGI server support? (Split SoupServer into SoupServerTCP
  and SoupServerCGI)

* Use gconf for config data
	* automatically pick up GNOME-wide proxy settings
	* rcd doesn't want more dependencies, so make this optional


General/API stuff
-----------------

* Thread safety
	* This is at mostly done, but need to figure out what other
	  things need to be thread-safe, and document which ones
	  aren't.

* Documentation (API, tutorial)
	* gtk-doc is not currently picking up all of the objects.
	  This probably has something to do with the fact that
	  some of the typdefs are in soup-types.h.

* User-Agent handling: caller should specify a User-Agent string to
  SoupSession, and soup should automatically append libsoup/#.## to
  that. (Likewise for Server/Via headers.)

* File-system-like asynchronous mode (eg, you write the request / read
  the response in as many pieces as you want. If you try to read or
  write more than you can, the EAGAIN is returned all they way to the
  caller, who must call the relevant soup function again later to
  continue reading or writing).
	   * needed if we wanted to do a soup-based gnome-vfs http
             backend

* Explicit support for Range header

* Merge SoupAuth and SoupServerAuth

* Merge SoupMessage and SoupServerMessage (allow chunked requests)

* Improve SoupServer handlers to allow for expect-continue handling,
  reading chunked requests a chunk at a time, etc.
	* Use SoupMessageFilter
	* Improving SoupServer's API will probably result in
	  completely breaking it.

* SoupProxy (based on simple-proxy, but better), which connects a
  SoupServer to a SoupSession with SoupMessageFilters in between.
	* Make it possible to implement CONNECT on the server side (by
	  having a way to steal the socket from the SoupServer).

* Add date-parsing/generating routines (all HTTP-specified formats)

* Special handling on server side for HEAD (don't send response.body).

* Simple higher-level API (a la E2kContext)
	* the Connector stuff has a lot of Exchange-specific
	  assumptions and exceptions. Might not be possible to
	  migrate Connector to a generic API


Testing
-------

* More regression tests

* Add apache config files to tests/ so that apache can be run locally
  to run regression tests against


Conformance
-----------

* Check handling of unknown HTTP versions [RFC ????]

* Don't do HTTP/1.1-specific behavior on HTTP/1.0 messages

* Preserve header ordering (on send and receive). Treat
  "Foo:bar\r\nFoo:baz" the same as "Foo: bar, baz"

* Enforce rules about what requests/responses MUST/MUST NOT have a
  body

* Encode space as "+" in URIs.

* Don't automatically process redirects on non-GET/HEAD requests

* Properly mangle HTTP/1.0 requests containing Connection headers
  [14.10]

* Automatically add Date header in SoupServer

* MUST observe DNS TTL information

* Make it possible to send/receive "OPTIONS * HTTP/1.1" (SoupURI won't
  currently accept "*")

* [get SHOULDs and SHOULD NOTs in]

