SourceForge has been redesigned. Learn more.


Sean Champ


I realize that Aserve is free/open source
software, and greatly do I appreciate it. I mean
not to be "pushy" or "demanding", certainly.

Before getting to this, I hope to mention: I would
be willing to make any code, for addressing
this, within aserve -- and to provide a patch for it
-- but I am not sure how this will "fly" with your
development team -- plainly, a team that I am not
a part of, and not acquainted with.

So, here is the issue, anyhow:

Regarding DO-HTTP-REQUEST, I had expected
that the forms of the function, in itself, would
handle the setting of any cookie that would be
returned by the web server -- not requiring that
this would be done outside of the function.

  • Motivation

The server may tell the client, 'SET-COOKIE" ,
and so the client may.

I consider DO-HTTP-REQUEST, as it being -- in
general and singular form -- "the client".

  • The Cookie Jar

Of course, DO-HTTP-REQUEST would need a
cookie-jar, in order to be able to set a cookie,.

DO-HTTP-REQUEST may be called, with or
without a cookie-jar argument. When it would be
called without a cookie-jar, then I would hope
that DO-HTTP-REQUEST would create a cookie
jar, itself, for the representation of the cookie that
the web-server would have directed the client to
have set.

  • Workaround

This works, though it may seem somehow
inelegant, when it would have to be done
outside of DO-HTTP-REQUEST:

(let ((cookie-info (ext:assq :SET-COOKIE
(when cookie-info
(save-cookie real-uri cookie-jar (cdr

In that code:
- REAL-URI would be the URI that was returned
- HEADERS would be the headers that were
returned by DO-HTTP-REQUEST

One more issue, tangential to the previous:

With the code -- a work in progress, and not
much worth sharing, quite -- the code that is
being used, before/around that example:
REAL-URI would be the URI, returned by

As such, REAL-URI might not be the exact URI,
that would have been provided to
DO-HTTP-REQUEST -- supposing that the
server might have redirected the client.

So, with that code, above, the URI, which would
be set to the cookie, might not match the URI,
which was provided to the HTTP request.

I presume, this might not be a problem. I'm not
even sure how it would matter, though -- fairly
new to HTTP, as yet.

If it would be a problem, that the request and
cookie URIs would not match, then I would be
glad to hear of it.

Regardless, I hope that this might be
addressed, in any form, within the aserve
documentation -- particularly, I would think, in
aserve.html -- so that anyone ,whom would find
such a question, later, might find it resolved, in
the documentation itself, of course. (I'd be willing
to edit the docs for this, but I'm pretty new to
aserve, in all.)

Thank you


Log in to post a comment.