On Sun, Dec 20, 2009 at 01:59:59PM +0100, Henrik Sarvell wrote:
> Apparently it was a GET request but I managed to parse it.
> (while (setq L (line))
> ((match '("G" "E" "T" " " @U " " "H" "T" "T"
> "P" "/" "1" "." @Y) L)
> (setq *Get T))
> ((match '(@Y "a" "t" "o" "m" @X) L)
I wouldn't match for the GET in the header loop. GET must be the very
first line, otherwise I would abort the transaction (like I wrote in my
previous example in case of POST). Also, no need for the global '*Get'
So this looks like an if/else condition. If GET is the first line, you
accept the variables from the URL, else if it is POST and "atom" is
matched, you read the XML.
> The problem now is that it seems like the prints are on the wrong
> channel, before when I was using the normal http etc in the @pubsub
> function I didn't get headers printed to my terminal for instance
> which I'm getting now. If I only can get the output to the right place
> I think I'm done.
What's missing here is a call to 'out'. Currently, the socket 'Sock' is
only used in 'in'.
(httpHead "text/plain; charset=3Dutf-8")
If the output channel is not set to 'Sock', it will write to whatever
channel is currently open (initially standard output).
BTW: I would not call '_htSet' here:
> (ifn (cdr (setq L (split L "=3D")))
> (cons (htArg (car L)))
> (_htSet (car L) (htArg (cadr L)))
As you see from the naming conventions, the underscore in the name
indicates a "local" function. And indeed, '_htSet' may call
which will crash your system if called in the wrong context. And it does
some permission checks on the variables which may not be suitable here.
'_htSet' does basically only a simple assignment, and follows some rules
of the application server which are not needed here, so I would
recommend to use something simpler, and more to the point.