World: r3wp

Does rebooting solved the issue?

Back to the old expect-arg issue after the reboot. Upping the post-mem-limit 
to way beyond the expected size of the posted files solved the issue, 
for now. This is not going to be a high-volume site, so that's no 
problem.

Testing on XP SP2 with Chromium 2.0.160.0, no issue here. If you 
could catch and send me the POST data, I could figure out what's 
going wrong.

is there anyone using cheyenne as a service on win xp home edition?

is there anyone using cheyenne as a service on win xp home edition?

I have a Cheyenne (enpro version) session running for a few months 
now on a Windows XP Pro.

well, I tried several times to run as a service on my xp home, it 
failed everytime

I tried that several times in 1 or 2 months, it failed.

but today after when I send this message it works as a service. stand-alone 
mode was always worked well.

so, problem solved mysteriously :?

Did you changed anything related to user rights? Maybe logged as 
Admin user now? Installing a service requires admin privileges.

No, I was always logged as administrator, I gave everyone full access 
to all the files and folders in cheyenne folder

service.dll was created

I can not reproduce the problem now

Strange. Any %crash.log file produced by Cheyenne?

no %crash.log file.

I have another problem / question: if cheyenne configured to execute 
rebol files (.r extension)

and if you put a plugin to your www folder

Cheyenne process script files declared in %httpd.cfg config file. 
In the default config file, you have :
	bind-extern CGI to [.cgi .r]

which means that both .cgi and .r are treated as CGI scripts and 
executed.

processes

then try to access that plugin from somewhere, like <PARAM NAME="LaunchURL" 
value="http://my-cheyenne/test.r">

then cheyenne processes the plugin's script

is there a workaround? without removing .r extension from cheyenne's 
config file?

If you want to serve .r files as static files, just remove it from 
the BIND-EXTERN command in config file.

yep, you got my point before I say :)

:-)

I want to execute .r files in cheyenne, so should I change the plugin's 
extension?

Yes, that's the correct solution.

ok, thanks. I'll try to reproduce the service problem, but currently 
it works well. thanks.

If you have issues again with the service mode, try running Cheyenne 
with the -vvv command line option to log debugging messages.

DEBUG: I'm I right that the newest version doesn't send a Rebol error 
to the client anymore? How can I re-enable this "feature" for non-web-app 
pages?

Something like: debug: true?

Does Chyenne support the HTPP request method DELETE out of the box? 
GET, POST & PUT work. But DELETE seems to be handled differently.

Web-Apps Login: Is the login page always presented as first page 
if a user isn't yet logged in and tried to access an other page directly?

Yes, in my experience, as long as the other page is in the web app 
directory. You can't even use an external CSS file in the directory 
until you log in, even if it is referenced from the login page.

Web-Apps Login: Is basic authentication supported? I have a situation 
where form-and-cookie authentication is awkward.

I think you can if you put it in public/ folder inside secured folder.. 
at least that's how it works here

I mean access css/js.. files

secured folder = web-app folder?

Oh, and cool, thanks. I really need basic authentication though, 
with no cookies required. Either that or to be able to specify sessionids 
as get parameters, or maybe post sometimes. I need to support stateless 
clients.

yes, <web-app>/public/

DEBUG: you're right. You can re-enable that by adding a DEBUG keyword 
in httpd.cfg in domain or webapp config block..

DEBUG: Can I enable it via a RSP API call or a flag for just a specific 
RSP file?

Let me see if it can be done easily...

I'm running Cheyenne in an EC2 instance, btw. Even the cheapest, 
bottom-of-the-line instance runs Cheyenne really quickly.

Try adding this line at the beginning of the RSP script (it shouldn't 
affect other scripts) : 

debug-banner/active?: yes

Is debug-banner page-local or app-local?

It's reset at every RSP request.

So, doing as explained would make it page-local.

DELETE: not out of the box. If you want to add support for new HTTP 
methods, you need to build a custom module for Cheyenne that would 
take precedence over mod-static/method-support handler. If you need 
it as RSP level only, you can just edit that handler and add whatever 
method you need. I may add a config option to be able to extend allowed 
methods in a cleaner way.