| Age | Commit message (Collapse) | Author |
|---|
|
In CHICKEN 6.0.0, the signature was documented to be different, but
we were using the actual signature. For later CHICKEN versions, the
signature was updated to match the documentation so now we're kind of
stuck having to support both signatures.
Since we cannot cond-expand our way out of this because there are no
features that differ between 6.0.0 and 6.0.1, we'll have to use
case-lambda and convert the old signature to the new one. Oh well...
|
|
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.
|
|
|
