World: r3wp

Nice

hum, problem with [get-env "REQUEST_URI"], I can't set-env ! Is there 
a simple way to set an environment variable from REBOL ?

no

I think you can set it for the session, but as soon as you reboot 
.. it's gone.

If not it can't run under Cheyenne without changing qm.r...but Chris 
said it has to work with Apache...:-(

kernel32: make object! [ lib: load/library %kernel32.dll win32api-GetEnvironmentVariable: 
make routine! [ name [string!] buffer [string!] size [ struct! [ 
size [integer!] ] ] return: [integer!] ] lib "GetEnvironmentVariableA" 
get-env: func [name [string!] /local size][ buffer: copy "" repeat 
sp 255 [buffer: append buffer " "] size: make struct! [size [integer!]] 
reduce [length? buffer] win32api-GetEnvironmentVariable name buffer 
size trim buffer ] win32api-SetEnvironmentVariable: make routine! 
[ name [string!] value [string!] return: [integer!] ] lib "SetEnvironmentVariableA" 
set-env: func [name [string!] value [string!] ][ win32api-SetEnvironmentVariable 
name value ] ]

making a custom module if just not enough, I need a way to set  "REQUEST_URI" 
env variable.

thanks :-)

except we are all testing under linux!

doh!

here's another one ...

kernel32: make object! [
lib:  load/library %msvcrt.dll

get-env: make routine! [
	varname [string!]
	return: [string!]
] lib "getenv"

put-env: make routine! [
	env-string [string!]
	return:    [integer!]
] lib "_putenv"

remove-env-var: func [name [string!]] [put-env join name "="]

env-var-exists?: func [name [string!]] [
	either "^@" = get-env name [false][true]
]

tz-set: make routine! [
	return:    [integer!]
] lib "_tzset"

free_lib: does [ free lib ]

]

since they both work while the app is running, I guess that's okay 
for windows.

Thanks, but still for win32, do you have one for linux ?

aren't linux env variables just disk files ?

don't know, possibly, but I'm on Windows, I can't test that for now...

http://www.linux.com/howtos/Secure-Programs-HOWTO/environment-variables.shtml

maybe that will help

Looks like it's stored in memory only : "In short, environment variables 
are internally stored as a pointer to an array of pointers to characters; 
this array is stored in order and terminated by a NULL pointer (so 
you'll know when the array ends). The pointers to characters, in 
turn, each point to a NIL-terminated string value of the form ``NAME=value''"

so need some wrapper script to set the env variables?

yes, /usr/bin/env

The problem is that 'REQUEST_URI' is Apache specific, it's not part 
of standard CGI...

I'll see how to handle that when my CGI generic module will be ready 
(for Cheyenne 1.0).

Sorry for QM, I don't have a simple solution to integrate it with 
Cheyenne, for now.

here is mod-rewrite for cheyenne http://reboot.ch/mod-rewrite.r

althought it may need some changes in cheyenne's core as well

I don't need Request_Uri specifically, just something that acts that 
way.  When I say I don't want to fork QM, I mean the script -- a 
few 'if find request/server-software "Cheyenne"' calls are not a 
problem.

For example, if there was a way of hijacking 404s, passing the 'request 
uri' as do/args to %qm.r, that would work too...

I customized 'mod-rewrites'  for Cheyenne by intercepting the requested 
file in httpd.r  works great.. much more powerful than Aoache's mod-rewrite. 
 Same would work for 404s

Doc, Chris, Cheyenne could just redefine get-env, couldn't it?

This gets it working, but doesn't honour existing files.  mod_qm.r 
(with qm at the top of the list of modules in httpd.cfg):

REBOL []

install-HTTPd-extension [
	name: 'mod-qm

	order: [
		url-to-filename last
	]

	url-to-filename: func [svc req conflo][
		req/in/path: "/"
		req/in/target: form req/in/file: %qm.r
		req/file-info: info? req/in/file
		req/handler: select svc/handlers req/in/ext: '.r
		false
	]
]

Then in the CGI handler, I changed this line (just to see if it works, 
not as a recommendation):

soc/path-info: data/in/url

Finally, in the 'request object in QM, I changed the Request_Uri 
line:

path: any [path-info get-env "REQUEST_URI"]

I recognise this may not be the correct usage of Path_Info, though 
I'm not sure what correct usage is -- the CGI spec explanation doesn't 
really clarify things...

Cheering squad: Give us a "C", give us an "h" ... Go "Chris"  


On a more serious note.  I've offered to help design/beta trial REBOL 
Want Ads.  QuarterMaster seems

like a candidate for this.  There isn't any time pressure, as this 
will take a while, but what is your gut feel for Cheyenne support? 
 From reading !Cheyenne you seem to have got a workable solution 
to get at the REQUEST-URI functionality?  Or was that just me reading 
with rose-coloured glasses?


Just FYI, the very first cut is going to be a blog.r test.  But I 
think rebols would appreciate a little more.

Thanks again by the way.

Sorry people.  This was meant as a private message to Chris...but 
now it's out there and that's...ok.
(Could you hear the Stuart Smalley impression?)

I have a 'workable' solution, but it still has a little way to go.

I'm still not sure how to stop the above code blocking some existing 
filetypes.

Ok, try this:
http://www.ross-gill.com/QM/mod_qm.html

It's mod_static with the 404 response replaced.

I've updated the QM source also to be Cheyenne friendly (still needs 
CGI query/post support):
http://www.ross-gill.com/QM/qm.html

Then the only other change in Cheyenne is to handlers/CGI.r
Replace "soc/path-info: none" "soc/path-info: data/in/url"

Ok, before I dig in.  The mod-qm.r replaces mod-static.r?  Or do 
I just slip mod_qm.r into the mods/
dir?

Slip mod_qm.r into the mods/ dir, then replace 'static with 'qm in 
httpd.cfg

Cool.  Doing...

Note, this expects that qm.r is at your www root.

Yep.

My Cheyenne installation has been modified, but I've noticed crashes 
when adding a trailing slash to an existing file (eg. http://cheyenne/index.html/). 
 I think this happens out the box in mod-static -- when you do info? 
%/path/to/file.r/ and file.r exists, it will return info/type of 
'file but when you read %/path/to/file.r/ you get an error.  Is this 
correct? -- view 1.3.50.3.1 core 2.7.0