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
|
To Do List for neon -*- text -*-
------------------- Id: TODO,v 1.3 2000/05/13 20:52:43 joe Exp
Please submit feature requests to <mailto:neon@webdav.org>
1. Support for HTTP-extended authoring methods ala WebRFM etc; using
New-URI header etc. Also support the BROWSE and INDEX methods. The
protocol is documented at:
http://www.ics.uci.edu/pub/ietf/webdav/ns_dav.html
2. Add proper domain support to authentication code. (requires full
URI parsing support). Need to tell the auth layer the server
details.
3. Add a callback to determine whether a specific request should go
through the proxy server or not... based on URI, maybe method too
since lots of HTTP/1.0 proxies break on DAV requests?
4. Better cnonce generation for authentication: use /dev/random or
whatever like mod_auth_digest.
5. Add request hooks to remove all authentication code from
http_request.c.
6. PUT/GET with ranges... http_get_range
7. hip_xml/dav_207/dav_prop might need a revamp.
hip_xml: use an expat-esque interface; i.e. make hip_xml_parser
opaque and add API to set handlers rather than initialize
structures directly. Two problems need to be solved more elegantly:
1) Allowing "sub-handler" for allowing parsing property element
contents independantly of the overally 207 response parse.
2) Allow "mixed-mode" parsing of XML which mixes cdata + elements.
Probably, make hip_xml more of a "utility" layer rather than a
"driving" layer; abstract out expat/libxml, namespace lookups,
element name -> id mapping, easy CDATA handling...
8. WebDAV class 2 locking. Problems: this requires parsing the XML
within a property element. This could be achieved by doing a
completely new XML parse of the property value returned by end_prop
from the 207 code, but this is a bit noddy. Options:
a) Ideally: extend hip_xml and the 207 layer to allow doing a
proper start/end_element/cdata parse of the XML *within* a
property. This is tricky since it means extending hip_xml to
*dynamically* determine whether to be in "collect" mode or not. Add
another callback for this?
9. DeltaV support (http://www.webdav.org/deltav/). See also the
inversion project (http://inversion.tigris.org/) who might build a
versioning system over DAV.
10. ACL support (http://www.webdav.org/acl/)
11. DASL support (http://www.webdav.org/dasl/). Xythos have server
support for this (www.sharemation.com).
12. SSL/TLS support... make it pluggable so we don't have to export
crypto-related code at ALL?
13. Should we really be abort()'ing on out-of-memory? It makes a lot
of code MUCH simpler (esp. sbuffer_* usage).
14. Nicer request-header manipulation... some kind of indexed data
structure, so we're sure we don't add the same header to the
request twice (e.g. Cache-Control). Must be at least as flexible
as sbuffer usage, though.
16. Socket status notification (socket.c:sock_register_*) is awful.
17. Should we really be i18n'izing the low-level error messages in
http_request.c, dav_207.c ? It seems nice and clever to, so the
user REALLY know what is going wrong with the server (probably),
but it is maybe a bit frightening.
18. PROPFIND/propnames support.
19. libtool support, for proper shared libraries.
20. Add full URI parser + handling. Or stop pretending we are doing
"URI" parsing, and just handle HTTP URL's.
21. Storing multiple authentication "sessions" within an actual
http_auth_session, so I log into e.g. /foo/ and /bar/ (which
are not in the same authentication domain)
switch between them without having to re-enter passwords all the
time.
22. Handle PROPFIND property error responses properly.
23. Mechanism for aborting a request mid-response; e.g., when a GET
fails due to out of disk space, abort the download.
24. In a PROPFIND response, if a property were to include e.g., a
DAV:multistatus element, this would not be handled correctly.
25. A BSD C library has an MD5 implementation in the C Library...
support this. (someone who runs a BSD will need to do this)
|
