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))
>                      (cond
>                         ((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'.

   (out Sock
      (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

   (throw "http")

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.

- Alex
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to