World: r3wp

So, how does a particular mod get invoked for an incoming url?  
How do I get the mod-rest.r to process the urls?

So, mods are able to process the various phases as described in cheyennes 
processing pipeliine. Each module can decide whether to process a 
phase, do nothing, and /or prevent another mod from processing that 
phase.

So, I guess if the mod-rest is not seeing the url-translate phase, 
one of the other standard modules has already processed it.

mod-static has this

	order: [
		method-support	last
		url-translate	first
		url-to-filename	last
		access-check	last
		set-mime-type	last
		make-response	last
		filter-output	last
		reform-headers	last
		logging			last
	]

So, I guess mod-static is processing url-translate first ... and 
I need to change this to 

url-translate normal

You shouldn't do that. If you want take priority other an existing 
module already declaring it's callback as 'first, you have to put 
your module after the other module in config file (modules section).

Oh .. so order is important there.

You can trace modules activity launching Cheyenne with -vvv option. 
You'll be able to see which module executes a given callback.

Order matters in modules [...] section.

I've already got mod-rest as first there.

I'll try the -www

The last one in the list will be the last loaded, so will be able 
to take the FIRST or LAST place even if other previously loaded mods 
did the same.

so, it has to be last then?

Your mod should be *after* mod-static.

ok.

18/10-08:16:29.195-[HTTPd] Trying phase url-translate ( mod-rest 
)

18/10-08:16:29.201-[HTTPd] Trying phase url-translate ( mod-static 
)
18/10-08:16:29.210-[uniserve] Calling >on-received< with {^M

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.