World: r3wp

The last entry was probably the cause of some of the rare "RSP freezing" 
issues. I've stumbled upon it recently while making a demo of one 
of our web-based products using IE7 through a proxy.  By default, 
IE7 switches to HTTP1.0 when connecting to a proxy causing the extra 
CRLF bytes after POST data to appear.

The issues I saw with Cheyenne were all related to IE and POST.

So, v0.9.20 is not released yet ?

Not yet, I'm still working on testing/fixing a few things and will 
add some minor features (like httpd.conf search path for Unix). Anyway, 
it should be out by the end of the month, I don't want to wait longer 
to release it.

All: If possible please hack all information that is useful for others 
as well into the Wiki. IMO that's the best way to build up a "documentation" 
for Cheyenne. And it frees Doc from answering the same stuff again 
and again.

What is this in reference to?

Doc. I have made a testing engine that simulates all sorts of http 
requests for testing my apps in rebol ... it so so works now, so 
I have to improve it still . .. you could also use that to create 
a pack of test suits for cheyenne and each time you make bigger changes 
you just run it and see if things behaved as suspected

Graham, you mean my post? Well, I thin Cheyenne is really nice and 
we should all help to make the docs better. And Doc has setup a Wiki 
for this.

So, who are you addressing?

Is there something discussed here recently that you think should 
be on the wiki?

For example that you can't use SSI from RSP at the moment. Etc. It's 
a general reminder for us all.

Janko, is your testing engine async ?

I'm not sure why you would want to use SSI from RSP .. but feel free 
to document it.

Will, no. It is not like load testing app or something like that 
, it is meant to test functionality of webapp backends -- if they 
do as they are supposed to

I never saw anyone using SSI. This is so oldschool :-)

Graham, read above. And Petr, it ight be old school but this doesn't 
imply it's not useful.

I haven't used SSI for over a decade ... and my recollection is that 
you can do all of that stuff in RSP.

doc, I really need your help.  I've tried quite a few things, and 
cheyenne is starting to behave more like a "chienne" than I would 
like.  ;-)


its funny cause I am trying to prevent cheyenne from doing its magic, 
and in effect, it feels like I'm trying to tell a shaman to stop 
having visions.

I'm almost there, but right now, when I close a connection, it effectively 
terminates cheyenne and all the task handlers    ' 8-o

Une chienne ! ça veut dire quelque chose de particulier en Québécois 
? Parce que pour un français ça fait assez vulgaire ;-)

ca veux dire la meme chose   ;-)

mais ca sonne assez similaire heheheh

Ah ok, j'avais pas saisi la blague :-)

it seems I cornered why cheyenne was dying on port close... yippe... 
but I still have a question.

I'm listening.

hehehe  I hope you didn't my above comment to harshly... its not 
a critique of the tool...  

let me make it clear... cheyenne is GREAT.


its what *I* am trying that is making it react strangely... but I'm 
understanding more and more as I beat it up.

Btw, you can run Cheyenne in verbose mode (-vvv or even -vvvvv), 
it's easier to debug this way. During the boot process, Cheyenne 
will list mods callback matrix allowing you to see/debug the execution 
order for your mod's callbacks.

Max, come one, I didn't yet lost my sense of humour :-)

one = on

first I want to confirm that     flag-stop, returned in most low-level 
funcs    is used to stop cheyenne itself.

yess I have used the verbose, and it has helped me a lot  ;-)

:-) 'flag-stop is a very low-level flag for UniServe allowing to 
quit the 'wait loop. You shouldn't mess with that when working at 
Cheyenne mod level (even at Uniserve's service/protocol level).

ok, that is what was killing uniserve earlier... now I can rest in 
peace with that issue.

second question: maybe not specific to uniserve, but you are probably 
the best suited to answer it, since you've most probably played the 
most with async ports.

IIRC, there's the built-in 'stop-events function available for UniServe's 
services/protocols to allow clean exiting from wait loop.

how can I make sure that I/O writing to an async port is finished, 
before I close it.

my current fix is less than elegant, and most definitely will trip 
a server under load... (wait 1  ;-)

IIRC, when writing on an async port in R2, you're supposed to set 
the 'write mode in port/async-modes. That will make REBOL keep calling 
port/awake function until all the data has been sent.

Not sure what you're trying to do, but, you shouldn't need to lost 
time of low level async stuff. UniServe is meant to offer a complete 
client and server API that should save you from working on low level 
stuff (unless what you're trying to do is not supported by UniServe's 
API).

of low = on low

no, what is happening is that task-handlers hang (for known and uniserve-independent 
reasons) so I can't rely on the normal uniserve system.


I must catch further connections as soon as possible, since they 
have to report errors without triggering the installed mods.  going 
through the different levels of apis, really complicates this handling, 
which now, basically is all done within the on-accept awake func 
of uniserve.


based on your note about the async I/O above, I think I'll add an 
extension to on-data to handle the specific case where that specific 
connection was refused, waiting for the error report to finish and 
I'm all set.

To make a more complete answer to your data sending question : I'm 
don't remember precisely, but I think that  REBOL signals that all 
the outgoing data has been processed by calling again port/awake. 
It's then, up to the programmer, to decide if :
    - there's more data to send

    - no more data to send, so get back to a read-only state (this implies 
    unsetting the 'write mode in port/async-modes)
    - the port needs to be closed.

in this system, I'm not even reading the request, just knowing that 
its httpd is enough for me to react appropriately.

Are you opening/closing the httpd service dynamically when some new 
connection is opened?

nope, just handling the connection itself.

when task handlers come back to life, the connections start being 
accepted again.

there are also alerts being sent for people to know that something 
is going on.

you see right now, I'm not even calling  init-connection  !

Why do you need to intercept it so early?

I've just re-read what you've explained yesterday. So you're doing 
some sort of soft firewalling inside "chienne"?