To recap where we stand after the IRC discussion today.

I've tried using (url) but it breaks in exactly the same way as
(redirect), so does (redirect) immidiately followed by (bye).

On Mon, Nov 30, 2009 at 8:50 AM, Henrik Sarvell <> wrote:
> Maybe this information will help a little. I am logged in at the
> moment (ie having a proper cookie), in Firefox and the app loads
> properly.
> I start Galeon (a mozilla based browser) and since I don't have a
> cookie there I get the login form, however upon submitting it I'm not
> redirected to /@desktop but to
> :46953/402748303615582...@start?*menu=3d+0&*Tab=3D+1&*ID=3D
> When I subsequently try to go to @desktop manually, I get the redirect
> headers in the result which means (usrQuit) was called:
> (de desktop (Uid)
> =A0 (rss-html
> =A0 =A0 =A0(if (; (usrQuit) feeds)
> =A0 =A0 =A0 =A0 (<script> "loadPopularWords('getPopularWords', 0, 'replac=
> =A0 =A0 =A0 =A0 (prin "Import some stuff and you will see something here.=
> (de usrQuit ()
> =A0(let Usr (getUsr)
> =A0 =A0 (unless Usr (redir "@logout")) Usr))
> However this is what I get in the content area:
> HTTP/1.0 303 See Other
> Server: PicoLisp
> Location:
> Content-Type: text/html
> Import some stuff and you will see something here.
> This is the headers and the error message so I suppose the redirect
> called by (usrQuit) isn't working properly.
> Meanwhile I'm able to use the application properly in Firefox where I
> do have a cookie, I think I'm going to try to investigate a little by
> doing a redirect in (start), then I would know if the problem appears
> with (redirect) even though I have a cookie.
> The picolisp I'm using is a 32bit version compiled on a 64bit machine,
> I hope this doesn't have anything to do with it.
> /Henrik
> On Sun, Nov 29, 2009 at 5:30 PM, Alexander Burger <> w=
>> On Sun, Nov 29, 2009 at 10:40:05AM +0100, Henrik Sarvell wrote:
>>> Yes the (patch _htHead '(format (car @H)) 0) line didn't help in the en=
d :(
>> OK, so we know at least that it is not a HTTP/1.1 problem.
>>> 1.) Started it and tried to break it by logging out and in a few times
>>> from different browsers.
>>> 2.) Went home a few hours later and tried from home and got it right aw=
>> Could it be that it has to do with some cookie timeout, or cookie vs.
>> client-IP mismatch? If it is not a race condition or some other
>> heisenbug, you should try to trace it down, to find out exactly where
>> things go wrong. I would start with -traceAll with stderr redirected to
>> a file like
>> =A0 ./dbg login-test/main.l-- -traceAll -g 2>errlog
>> Cheers,
>> - Alex
>> --

Reply via email to