Re: Customizing http access
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'
then.
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.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Customizing http access
Apparently it was a GET request but I managed to parse it.
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.
Here is what I have at the moment:
(de go ()
(rollback)
(task (port 4000)
(let? Sock (accept @)
(unless (fork)
(in Sock
(off *Xml *ContLen *Get)
(use (L @X @Y @U)
(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)
(setq *Xml T))
((match '(~(chop "conte...@ength: ") . @X) L)
(setq *ContLen (format (pack @X))
(cond
((and *Xml *ContLen)
(setq *Xml (ht:Read *ContLen)))
(*Get
(setq
L (split @U "?")
L (mapcan
'((L)
(ifn (cdr (setq L (split L "=3D")))
(cons (htArg (car L)))
(_htSet (car L) (htArg (cadr L)))
NIL ))
(split (cadr L) "&")
(cond
(*Get
(httpHead "text/plain; charset=3Dutf-8")
(and
(=3D "vizual" (req 'hub.verify_token))
(=3D "subscribe" (req 'hub.mode))
#(db 'xmlUrl '+Feed (req 'hub.topic))
(prin (req 'hub.challenge
(*Xml
(hubSubImport> '+Rss *Xml)
(httpStat 204 "No Content"))
(T (http404)
(bye))
(close Sock)))
(server *UsePort "@start"))
On Sun, Dec 20, 2009 at 10:56 AM, Henrik Sarvell wrote=
:
> In this special case I don't need to extract url parameters just the
> POST contents in the case of verification.
>
> So I'll incorporate the POST match and give it a try.
>
>
> On Sun, Dec 20, 2009 at 8:52 AM, Alexander Burger w=
rote:
>> On Sat, Dec 19, 2009 at 05:31:24PM +0100, Henrik Sarvell wrote:
>>> wonder about is the part where a "normal" request would be split and
>>> its keys =3D3D> values would parsed. Is that part enough or is there
>>> something else happening in the big/original flow?
>>
>> I would check for the initial POST, so that erroneous connections are
>> discarded:
>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 (in Sock
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(off *Xml *ContLen)
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(use (L @X @Y)
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (use (L @U @H @X @Y)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(when
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(and
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (line)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (match '("P" "O" "S"=
"T" " " "/" @U " " "H" "T" "T" "P" "/" "1" "." @H) @) )
>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (while (setq L (line))
>>
>> Also, you might perhaps need '@U' later to extract URL parameters.
>>
>> I cannot see other things at the moment that might be needed here.
>> Further parsing of arguments, or permissions checks are not necessary,
>> right?
>>
>> Cheers,
>> - Alex
>> --
>> UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe
>>
>
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Customizing http access
In this special case I don't need to extract url parameters just the
POST contents in the case of verification.
So I'll incorporate the POST match and give it a try.
On Sun, Dec 20, 2009 at 8:52 AM, Alexander Burger wro=
te:
> On Sat, Dec 19, 2009 at 05:31:24PM +0100, Henrik Sarvell wrote:
>> wonder about is the part where a "normal" request would be split and
>> its keys =3D3D> values would parsed. Is that part enough or is there
>> something else happening in the big/original flow?
>
> I would check for the initial POST, so that erroneous connections are
> discarded:
>
>> =A0 =A0 =A0 =A0 =A0 =A0 (in Sock
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(off *Xml *ContLen)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(use (L @X @Y)
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (use (L @U @H @X @Y)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(when
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (line)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (match '("P" "O" "S" =
"T" " " "/" @U " " "H" "T" "T" "P" "/" "1" "." @H) @) )
>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (while (setq L (line))
>
> Also, you might perhaps need '@U' later to extract URL parameters.
>
> I cannot see other things at the moment that might be needed here.
> Further parsing of arguments, or permissions checks are not necessary,
> right?
>
> Cheers,
> - Alex
> --
> UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe
>
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Customizing http access
On Sat, Dec 19, 2009 at 05:31:24PM +0100, Henrik Sarvell wrote:
> wonder about is the part where a "normal" request would be split and
> its keys =3D> values would parsed. Is that part enough or is there
> something else happening in the big/original flow?
I would check for the initial POST, so that erroneous connections are
discarded:
> (in Sock
>(off *Xml *ContLen)
>(use (L @X @Y)
(use (L @U @H @X @Y)
(when
(and
(line)
(match '("P" "O" "S" "T" " " "/" @U " " "H" "T" "T"
"P" "/" "1" "." @H) @) )
> (while (setq L (line))
Also, you might perhaps need '@U' later to extract URL parameters.
I cannot see other things at the moment that might be needed here.
Further parsing of arguments, or permissions checks are not necessary,
right?
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
