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
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
Cactus Code Thorn HTTPD
Author(s) : Gabrielle Allen
Tom Goodale
Thomas Radke
Maintainer(s): Cactus team
Licence : LGPL
--------------------------------------------------------------------------
1. Purpose
This is a prototype C version of a web server thorn.
[Note that it has not been audited against buffer overruns or other
security problems, so please be aware that it is possible that someone
could exploit this server to access your machine if you run the server
on an open network.]
Usage:
-------------------
Interface:
---------
The current interface for this webserver is contained in
http_Request.h
(Note that this will change once we have an agreed common protocol for
other thorns to talk to web-serving thorns.) There are also utility
interface for parameter steering and HTTP authentication, which are
described in the files in the doc directory.
The primary mechanism is to
HTTP_RegisterPage(path, function, data)
where 'path' is the URI you want to register, e.g.
/parameters
'function' is a function of the form
int foo(const cGH *cctkGH, httpRequest *request, void *data)
which will be called when the page is accessed, with 'data' being the
same data pointer that was passed into the registration routine.
Note that a request of the form '/foo/bar/' will look for a page of
the called '/foo/var/index.html' first, followed by '/foo/bar',
followed by '/foo' followed by '/'.
The httpRequest structure contains various pieces of information -
request->body The body of the http request. This is
empty for a GET.
request->body_length The length of the body.
request->method The http method.
request->uri The full URI of the request.
request->residual The URI remaining after the registered URI
is removed from it.
request->http_major_version The major version of the HTTP protocol
used.
request->http_minor_version The minor version of the HTTP protocol
used.
request->n_arguments The number of arguments passed to the
request.
All other members of the structure should be considered opaque.
To get details of arguments or HTTP header lines, the functions
const char *HTTP_ArgumentValue(const httpRequest *request,
const char *arg);
const char *HTTP_HeaderValue(const httpRequest *request,
const char *header);
may be used. Given the name of a header field or an argument, these
functions will return the corresponding value, or NULL if the argument
or header does not exist.
There is also a function
const httpArg *HTTP_ArgumentWalk(httpRequest *request, int first);
which will walk through all the arguments passed to a page. If
'first' is true it will start with the first argument, otherwise it
will start with the next argument after the last one queried.
Currently this is the only way to get arguments which are passed in
more than once. The httpArg structure contains two public variables
arg The name of the argument.
value The value of the argument.
Writing to the browser:
----------------------
This is done with the
HTTP_Write(httpRequest *request, const char *buffer, size_t count);
function. This takes three arguments - the request, a buffer, and the
length of the buffer.
The first line sent to the browser should be
HTTP_Write(request, "HTTP/1.0 200 OK\r\n",19)
(or an error code, e.g. "404 Not Found"). This should be followed by
any HTTP headers, such as "Content-Type", followed by "\r\n\r\n" and
then the content of your page, or at least that's what the standard
says 8-). You may make as many calls to this function as you like to
get the data to the browser.
Examples:
---------
For examples of how to use the interface, please look at the Content.c
file.
Structure of the thorn:
----------------------
The thorn is split into three parts - basic web serving, utilities,
and content provision
Web serving:
-----------
The web server capabilities are held in
Sockets.c - basic socket utilities; these should be
replaced by or moved to the Socket thorn.
Server.c - Stuff to register and serve pages.
http.c - Parsing of HTTP requests.
Startup.c - normal scheduled stuff.
The above files should not need to be touched apart from debugging
purposes, to add more HTTP methods, or otherwise to enhance the
interaction with the network and protocols.
Utilities:
_________
The web server provided utilities to help content provision -
Steer.c - parameter steering interface
- see doc/Steering.txt
Authorisation.c - HTTP authentication
- see doc/Auth.txt
Content Provision:
-----------------
The content provision is currently in
Headers.c
Content.c
Groups.c
Parameters.c
This makes use of the interfaces in http_Request.h described above to
provide content. In principle this could be in another thorn, but
that should wait until we have an agreed set of interfaces to allow
web-server thorns to be interchangeable, at least at compile time, but
hopefully at run-time.
|
