will get updated before writing out the response, not only those that
happened to be generated via the access-resource standard method.
This might lead to redundant calls to update-entity-headers, which
might be costly, so maybe some form of last-updated time-stamp should
be kept so that update-entity-headers isn't called more than once a
second.
This fixes the problem we had with Netscape's Proxy-Server: Since
update-entity-headers wasn't called on e.g. redirector-resource
responses, those didn't contain content-length headers. This
triggered a bug in Netscape's Proxy-Server (version 3.5 at least),
which kept the connection open even after the explicit close by
CLASH.
strings, i.e. to accept junk after a valid date specification. This
is in order to support e.g. Netscape 2.x upto 4.7x, which illegally
send an added length field in the If-Modified-Since header, i.e.:
If-Modified-Since: Wed, 28 Mar 2001 05:40:23 GMT; length=5912
This unconforming behaviour is known since 1996, yet nothing ever
changed. How sad.
thinking?) and rewrote the whole outbound entity stuff instead. This
fixes some of the problems, but the whole entity stuff really needs a
complete rethink, especially w.r.t. integrating inbound and outbound
entities. Maybe we should drop "intelligent", persistent entities
completely, and revert to dumb, transient entities, with the
intelligence lying in the resources.
requests and entities are now parsed. Furthermore the whole
request-entity handling has been changed to allow lazy parsing, parsed
entity headers, and flexible choice of entities. This is all to
support the handling of MIME multipart entities, especially
multipart/form-data. The current revision is a first cut, and some
further rewrites are needed.
query url requests. This is probably a stop-gap measure, until a more
general context processing framework (including session and validation
data) has been designed and implemented.
request read on a connection, which allows us to generate the correct
type of response in case of an error which is handled through
`handle-server-error'.
Also added code to correctly escape text that is inserted into error
messages. This is also a first step towards preventing cross-scripting
attacks through CLASH, although most of the code still has to be audited
for unfiltered passing through of user-supplied text.
with Allegro CL in "modern" mode. Although we don't think that
"modern" mode is the correct approach to case-sensitivity in CL, the
changes we made should also make it easier to work in ANSI-compliant
implementations/modes, with all the settings for readtable-case. Note
though that this is a first best effort attempt, and so further
case-ification bugs might still remain. YMMV.
response-header. Rewrote error handling code to provide more
information in the body. Adjust `read-request' to pass the connection
to `parse-request', see changes in messages.cl.
quoted-strings in both key and values of key value pairs and in simple
lists correctly. Also factored out all magic constants, added some
stuff to make this halfway efficient (profiling to be done). This
rewrite makes partition superfluous, maybe remove this from
src/utility.cl.
Added parsing of Base64 and authorization credentials.
instead of the stream, in our effort to reduce the passing around of
streams. This is also necessary in order to allow request handlers to
check for the address and/or hostname of the connection the request
came in from. Changed `parse-request' accordingly. TODO: Rendering
of messages should probably change over, too.
Added handling of Authority request-header, and WWW-Authenticate
response-headers. Changed order of response-header rendering to
follow RFC guidelines. Added automatic generation of Server
response-header, added correct handling and automatic initialization
of Date response-header. This should bring us closer to correct and
full handling of at least all HTTP/1.0 headers in responses. Request
parsing of some headers remains to be done.
Added ignore declarations to quiet the compiler.
versions of CMU CL, as well as guarding against short reads by
read-sequence on socket streams, though my understanding of the
standard seems to imply that read-sequence can only return prematurely
on EOF. But this way we shouldn't have any problems either way.
