World: r3wp

If it's in encap mode, try running it with admin rights.

While testing now, I've noticed a few issue with send-email/attach: 
header and multipart/form-data encoding. I'll fix them tonight, need 
to go now.

I was just doing a straight text test .. but no go.  Even in administrator 
mode.

Not sure how to turn on logging when running as admin ..

Can I use virtual hosts to serve multiple document roots on the same 
site without having separate domain names? I I would like to avoid 
"creeping" between multiple sites that don't share code and also 
use it as a tool to avoid the browser accessing code directories 
for the site.

suppose I have:

somewhere/site1
somewhere/site2

and I don't want

somewhere/site2/../site1 == somewhere/site1

I think I found a different way to do this with symlinks. Thanks.

hmmm... it did not solve it.

Henrik: Use Webapps

Maybe alias can do as well, look in heepd.cfg, there are examples 
for both

I think webapps require a bit more than static pages?

also alias is not working for me.

It seems that webapps don't require more than an index.html file 
to work, but I get a 404 back or a redirect to the previously shown 
page, when I put an empty index.html file in that dir. When the file 
has just one char, it's served properly.

Like so:

1. create dir test/ in the doc root folder.
2. create empty file index.html in test/
3. try to display in browser: no go
4. insert char "a" in index.html
5. "a" is displayed in browser.
6. remove "a" again so index.html is empty
7."a" is still displayed in browser.


If I navigate away and then back to that page using the Back button, 
it still faithfully displays the "a".


If I directly enter the url for the index.html file, I get bounced 
back to the previous URL.

webapp won't work, even with an app-init.r file, but it works fine 
with an HTML page.

I guess what I really want is the feature of virtual-root for a webapp, 
but just for plain RSP pages.

Another potential issue is when a virtual-root has the same name 
as a real directory at the default root dir. I don't know if that 
can be warned for, but it caused some confusion here before I figured 
out what was wrong.

I'm bubbling with question regarding webapps. :-) Because I can't 
get them to work according to what is written in the docs.

webapps work fine for me.

maybe your browser is caching.

attempt [load join request/config/root-dir %/app-init.r] ; TBD: report 
errors !!!

Maybe it's this line in the code that is giving me issues.

because app-init.r is quietly not run

my curecode works fine, but my own app does not work

cure code is a web app is it not?

RSP: error in events from %app-init.r now logged.

That's from the change log. That's not correct.

for cheyenne 0.9.19.

yes, it's a webapp.

I'm not entirely clear at all from your description what the issue 
is.  But I presume doc is working on fixing the email issue and if 
there are others ... he'll get on to them.

In the meantime I am holding off deploying the latest SVN version 
of Cheyenne.

Sorry, if I'm rambling a little bit. It's what I'm observing that 
is straight reposted here. Moving a few milimeters forward after 
a whole day's work is a bit frustrating, particularly when it's REBOL. 
:-)


Right now I just see that app-init.r is not run and that the loading 
of it is wrapped in an ATTEMPT in Cheyenne's source, so I basically 
can't see what's going on. From the docs it appears that the app-init.r 
file is required for a web-app, but request/web-app returns a web-app 
name. So am I running a real web-app or what's going on?

remove the attempt

and log the error instead

cheyenne straight out of svn comes with a web app .. does that work?

I use the encapped version here.

of cheyenne?

can't re-encap or switch to using source version?

after a lot of experimentation, the latest encapped version was the 
only one that worked properly.

So, which encapped version is faulty and which one works?

Doc needs to remove faulty binaries if they are still available for 
download.

is there any real advantage to using the binary version of cheyenne 
wrt the source version?

Yeah .. users can corrupt the source files

how is that possible?

if you have uniserve and cheyenne.r ... of course they can fiddle

by users you mean the people running the server or web users?

oh ... I distribute cheyenne to end users as an embedded web server

ah ok, yeah in that case you want to give them the bin.

but I really meant, feature-wise...

don't think so

btw, the svn setup is cool  :-)  good work doc

I wasn't particularly favoring the binary version, only that after 
a day's experimentation, that was the only one that worked properly 
for me. When in such a situation, it's better to stick to one with 
known bug record, so I can tell whether it's the binary or me that's 
doing something wrong.