-
Notifications
You must be signed in to change notification settings - Fork 10
/
notes.txt
147 lines (91 loc) · 4.12 KB
/
notes.txt
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
-*- mode: markup; -*-
* What I did
** Gross stripping
Senselessly removing all :documentation just to have less to look at.
De-genericizing.
* Reorganization ideas
Acceptor should not know about SSL—or maybe it should and we should
get rid of SSL acceptor; the acceptor can be parameterized with
something that changes the default port and which replaces the stream.
My send-headers-and-wrap stream should be built in—there should be an
easy way for a response generator to specify that it wants a bivalent
stream. Or maybe setting an external format on the reply should cause
it to happen. (Hmmm, perhaps the right place is for SEND-HEADERS to
take an argument saying what kind of stream it wants. The default
could be a bivalent stream and you could specify :binary t to save the
cost of creating the flexistream.)
Mime-type data should be moved out of code.
Perhaps the reply and request objects should be passed in to handler
functions rather than as special variables.
* To do
Get rid of foo* functions. (Will presumably happen if *reply* and *request* are passed explicitly.
Where is the proper place for session handling? Get rid of sessions
machinery?
Break out logging into a separate object.
Possibly combine request and reply objects into a single object.
* Threading
create-request-handler-thread assumes that we will create
* Bugs?
If you connect to an SSL acceptor with HTTP it hangs. Seems like something else should happen.
* Things a user may want to configure or customize.
** Dispatching
Acceptor reads an HTTP request and populates the request/reply object.
Then what code runs is up to a higher level dispatcher. We may want to
provide some simple ones.
** Error pages
When a request is handled, it may abort the handling of the request
with an HTTP status code indicating an error. The handlers should not
have to worry about generating an appropriate error page. There should
be a default error handler that generates Toot-branded error pages and
there should be an easy way to provide your own code to generate error
pages.
Logging (where to and what format)
* Flow
[acceptor] start ->
[taskmaster] execute-acceptor ->
[acceptor] accept-connections (in new thread) ->
[taskmaster] handle-incoming-connection ->
[acceptor] process-connection (in new thread for each connection)->
[request] process-request (in loop) ->
dispatch to user code.
* Response generation
process-request calls start-output to send an http-internal-server-error
send-headers calls start-output with no content
start-output calls send-response
* Random ideas
Instead of a handler just being able to return a string, perhaps it
can return any object for which there are methods defined that can
figure out how to render it and what the size of the rendering will
be.
(defgeneric render-body (object stream))
(defmethod render-body ((object string) stream)
(write-string object stream))
* Renaming
headers-in -> request-headers
header-in -> request-header
headers-out -> reply-headers
header-out -> reply-header
return-code -> http-status-code or status-code
* For docs
Note that server-protocol is taken from the request line so is
something like :http/1.1 or :http/1.0. It will be one of thes even if
the request was made over HTTPS.
* Reading post data
post-parameters -> maybe-read-post-parameters -> raw-post-data -> read-request-body
maybe-read-post-parameters -> parse-multipart-form-data -> parse-rfc2388-form-data
1. Request comes in.
2. Read headers. Stream is sitting at body. Handler is invoked.
3. Handler code may:
1. Ask for post parameters. Toot reads and parses them. Stores alist
in request object for later retrieving individual parameters. If the
request is multipart/form the post-parameters values will contain
lists including the name of the tmp file where the file upload
elements were saved.
2. Ask for the stream. Give it to them. They can do whatever they
want.
3. Ignore the post data. Do nothing.
4. Request has been handled. Drain stream and discard.
* To do:
charset, external-format, encoding audit
* Logging
See this for Apache compatibility http://httpd.apache.org/docs/1.3/mod/mod_log_config.html#formats