World: r3wp

url-translate is returning 'true in mod-rest, but mod-static is still 
being called

That's odd.

True	 Request processed. Prevent other modules from processing this 
request (for the current phases).

That how it's supposed to work.

ahh....

what's this line do?

		if not find/part req/in/url "/@" 2 [return none]

It give up on processing the request and pass it to other mods.

gives

so that's happening

Only URLs starting with /@ pattern will be processed by this mod's 
callback.

is that because the examples I gave you had /@ in them?  :)

Yes :)

ok ;)

Things are a lot clearer now :)

It's probably a good idea though ... makes it easy to process the 
rest requests from others

If you use a url like

http://user:[password-:-localhost]/


where is the user and password captured?  I see the browsers FF and 
Chrome immediately remove the userid/password from the address bar. 
 IE complains that it's not a valid site

It's not in req/auth which is empty

and it's been removed already from req/in/url

before the url-translate phase

It's passed though WWW-Authenticate header. See  http://en.wikipedia.org/wiki/Basic_access_authentication

doh ... I think I knew that!

I've done enough masquerading with Rebol as a http client!

Amazing how much stuff one forgets :(

And I see my problem ... I was looking for header information in 
url-translate prior to the headers being parsed which is why I couldn't 
see that information.

Graham, as you have a fresh eye on mods building, if you notice things 
that might be improved, I'll be glad to hear your comments.

as far as I can tell ...just need more docs :)

As in, more Dockimbels to develop on it? ;-)

Well, I made only a few changes and got this far

http://rebol.wik.is/Cheyenne/Mod-rest

I'm creating an API, and each api word maps to a single rsp page 
inside a %rest directory.  It is up to the rsp page to decide which 
actual function is being called, and to deal with all the parameters.

And also to deal with authentication.  Basic authentication will 
be used for each api call .. and the whole site will be behind https.

so, DELETE /@api/fax/jobno and GET /@api/fax/jobno both map to the 
same rsp page.

This scheme sound okay?

I'm not a REST expert, but your code looks ok to me so far.

Tunneling Basic authentication through SSL is a wise decision.

What's the purpose of the .cache.efs file  that gets written . I 
think this was the file I saw before that I didn't have writes to 
write to the local filing system

rights to to write

It's the cache generated for encapping Cheyenne by my encap-fs library. 
It's needed only for encapping.

Is the captcha library still working for other people on v 19 ?

Not working so far for me.

fordidden: charset "iIl1LoO0*àçèéêù"
	allowed: exclude charset [
		#"0" - #"9" #"A" - #"Z" #"a" - #"z" "@àçèéêù*"
	] fordidden

I think you meant 'forbidden

set-fonts-path: func [value [file!]][fonts-path: dirize value]

but set-fonts-path is not called inside 'captcha.r

I've got this in app-init.r


on-application-start: does [
	;--- add here your library / modules loading
    do %private/captcha.r
    captcha/set-fonts-path %private/fonts/
]
but for some reason the do %private/captcha.r is not firing.

More testing. If I remove this code form app-init.r it does not work.
If I don't have 

do %private/captcha.r
captcha/set-fonts-path %private/fonts/

also in my login.rsp, it doesn't work.

So, in summary I need this code both in app-init.r and in my login.rsp

Didn't tested the Captcha code with v19, as a workaround try to move 
the code from on-application-start to on-session or use *do (instead 
of 'do) in on-application-start.

tried that too

*do

I think ... will try again.

Nope, neither of those work.  I neeed to have the code in my login.rsp 
page as well.

Tried again ... *do does work afterall.