1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
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]
|
