| Age | Commit message (Collapse) | Author |
|---|
|
This is now using read-bytevector instead of read-string, and the
custom port constructor uses keyword arguments now.
Don't bother to use cond-expand to make it compatible with C5.
Instead, we can cut new C5 releases from the intarweb-2.x branch if
necessary.
|
|
|
|
|
|
Corrected the handling of the Range request header and the Content-
Range response header. They now have separate parsers, to match the
standard, and the content-range unparser is now correctly named.
The Range header can be in one of three forms:
Range: bytes=<start>-<end>
Range: bytes=<start>-
Range: bytes=-<end>
The Content-Range header can be in one of three forms:
Content-Range: bytes <start>-<end>/<size>
Content-Range: bytes <start>-<end>/*
Content-Range: bytes */<size>
The unit tests were updated to reflect the changes.
Signed-off-by: Peter Bex <peter@more-magic.net>
|
|
|
|
Unlike the srfi-1 linear updating procedures with exclamation marks, in
srfi-13, the side-effecting operations do *not* necessarily return
the string. They just mutate it in-place.
This fixes #1826, so that it will work with utf CHICKEN (upcoming C6).
|
|
|
|
This is a procedure that can be used by users of this egg which
need the string representation of the Date header (for signing
purposes, for example, like the S3 egg needs for the AWS signature)
The problem is that we don't really want to bake in "letlocale"
in all other programs, but contain this horrid complexity in intarweb.
|
|
|
|
Keywords can't be (ab)used as identifier anymore, so we can't bind
expression: with let-syntax. Instead, simply use the plain symbol.
|
|
|
|
|
|
|
|
|
