Another recap after doing stracing, it seems a "serious" application
needs to be started like this: ./p main.l -go -wait >> rss-reader.log
2>&1 &

I wasn't doing that and my site was subsequently visited by bots
(hence the random feeling time factor that was involved) which
triggered output on stderr, which I hadn't directed to a log file,
which in turn somehow tripped up the redirection in picolisp, hence
the strange problems I experienced.

After starting with the above line I haven't been able to reproduce the pro=
blem.

Maybe Alex can elaborate?

/Henrik



On Mon, Nov 30, 2009 at 11:17 PM, Henrik Sarvell <hsarv...@gmail.com> wrote=
:
> 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 <hsarv...@gmail.com> wrot=
e:
>> 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, 'repla=
ce');")
>> =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: http://vizreader.com:80/@logout
>> 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 <a...@software-lab.de> =
wrote:
>>> 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 e=
nd :(
>>>
>>> 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 a=
way.
>>>
>>> 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
>>> --
>>> UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe
>>>
>>
>
-- 
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to