From 258821572b53730a7d7e52ef8a3ed3c9ad960e23 Mon Sep 17 00:00:00 2001 From: Dan Winship Date: Fri, 25 Nov 2005 18:46:27 +0000 Subject: sync to text on wiki, and point to wiki * README: sync to text on wiki, and point to wiki * TODO: moved to http://live.gnome.org/LibSoup_2fToDo --- ChangeLog | 6 +++ README | 17 ++----- TODO | 163 -------------------------------------------------------------- 3 files changed, 11 insertions(+), 175 deletions(-) delete mode 100644 TODO diff --git a/ChangeLog b/ChangeLog index 0afe2e42..2c0ec09a 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2005-11-25 Dan Winship + + * README: sync to text on wiki, and point to wiki + + * TODO: moved to http://live.gnome.org/LibSoup_2fToDo + 2005-11-17 Dan Winship * libsoup/soup-message-io.c (io_cleanup): clear priv->io_data diff --git a/README b/README index 947611d3..4fb1a98c 100644 --- a/README +++ b/README @@ -1,17 +1,8 @@ -Soup is an HTTP library implementation in C. It was originally part of -a SOAP (Simple Object Access Protocol) implementation, but the SOAP -code was later removed (and then later partially reimplemented...) - -Soup uses GObjects and the glib main loop, and is designed to work -well with Gtk/GNOME applications. This enables GNOME applications to -access HTTP servers on the network in a completely asynchronous -fashion, very similar to the Gtk+ programming model (a synchronous -operation mode is also supported for those who want it). - -Soup also contains code to implement an HTTP/1.1 server. +libsoup is an HTTP client/server library for GNOME. It uses GObjects +and the glib main loop, to integrate well with GNOME applications. Features: - * (Optionally) completely asynchronous + * Both asynchronous (GMainLoop and callback-based) and synchronous APIs * Automatically caches connections * SSL Support using GnuTLS * Proxy support, including authentication and SSL tunneling @@ -22,6 +13,8 @@ See the test programs in tests/ for simple examples of how to use the code, or evolution-data-server and evolution-exchange for more complicated examples. +More information (including future plans) may be available at +http://live.gnome.org/LibSoup To subscribe to the Soup discussion list, send mail with the word "Subscribe" in the message body to soup-list-request@ximian.com. diff --git a/TODO b/TODO deleted file mode 100644 index 3ceebee5..00000000 --- a/TODO +++ /dev/null @@ -1,163 +0,0 @@ -Known bugs/FIXMEs ------------------ - -* 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 - -* Expect: 100-continue processing doesn't currently abort sending - the body if it gets back a non-informational status code - -* SoupConnections never time themselves out. They always wait for the - server to time them out (and even then they don't time out until you - try to use them again). - * NTLM connections should stay open longer than plain ones - -* SoupSessions tend to get leaked because of circular refs (each - connection refs its session as a SoupMessageFilter) - -* URI encoding bugs - * query component at least, maybe others must be stored - fully-escaped, because only the endpoints know which - chars are and aren't reserved - * When fixing this, also consider: - * Merging E2kUri with SoupUri - * application/x-www-form-urlencoded, which encodes - space as "+" rather than "%20" - * SoupUri doesn't currently allow "*" as a URI - -* soup_session_queue_message() does nothing on SoupSessionSync. - -* soup_xmlrpc_value_get_base64() returns the encoded value, not the - decoded value. - -* The synchronous SoupSocket API is slightly broken. This is mostly - not a problem for the HTTP engine, but it's obvious in - tests/revserver.c that the stack will eventually overflow. The fix - is to have SoupSocket return WOULD_BLOCK when changing direction, - and require the caller to unroll the stack back to the top level in - that case before trying again. - - -HTTP Features -------------- - -* Handle gzip Content-Encoding - -* Handle cookies (RFC 2109) via a SoupCookieJar message filter - * libexchange has some minimal cookie functionality for - Exchange 2003 forms-based auth - * RFC 2965 supposedly obsoletes 2109, but I don't think - anyone uses it. (Yeah, grep for "cookie" here: - http://www.nextthing.org/archives/2005/08/07/fun-with-http-headers) - -* 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 ---------------------- - -* Bring back WSDL compiler from old soup module? - -* The current SOAP/XMLRPC 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 using - g_string_append... - - -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, including - ignore_hosts, etc - - -General/API stuff ------------------ - -* Documentation (tutorial, hacking, thread safety) - -* 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). - -* 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 - * jamesh's HttpResource object - - -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 - -* 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 - -* [get SHOULDs and SHOULD NOTs in] - -- cgit v1.2.3