AltME groups: search

so that is the rsp you request that generate the file and upload 
it to google

I'd like to see the response headers of that request , not those 
from requesting the uploaded file

I got the comodo certificate now .. I got my crt and 4 immediate 
crts and 1 root crt .. got to figure out how to use this with stunnel 
now .. the example shows that you have .pem file

I read here .. I concatenated them together accordingly , now I get 
---

2009.08.23 10:51:23 LOG3[17421:139883801568992]: SSL_CTX_use_RSAPrivateKey_file: 
B080074: error:0B080074:x509 certificate routines:X509_check_private_key:key 
values mismatch

I keep getting key values missmatch nomatter what I tried so far... 
I found out this.. the key/cert/CAfile in conf doesn't seem to matter 
as it checks /etc/stunnel/stunnel.pem anyway .. so I commented them 
out. 


If I delete the pem file I get appropriate erros , so it checks for 
this file.. 

If I remove RSA PRIV KEY from first line I get Error saying something 
about RSA KEY no start line

If I remove CA certificates below I det Error saying SSL CERT  no 
start line .. 
If I concat them all like this 


>> cat myserver.key AddTrustExternalCARoot.crt UTNAddTrustSGCCA.crt 
ComodoUTNSGCCA.crt ComodoHighAssuranceSecureServerCA.crt www_cebelca_biz.crt 
>> stunnel.pem 

(first the PRIV KEY ALL THE CERTS in same order as they are listed 
in email to me.. with cebelca.biz.crt as last I get the "key values 
missmatch" which I think means that the priv key and certs don't 
match

I tried using the pem file I can generate on stunnel page and I see 
that it's certs and privkey are half shorter... maybe I don't have 
tre right version type or something of encription setup?

I use apache2-MPM as a reverse proxy in front of Cheyenne for the 
same reasons (static serving, ssl), works flawlessly, but now is 
time to move to nginx. Looking at MacPorts variants for nginx, there 
are many options that I see interestings:
root/trunk/build alpha% port variants nginx
nginx has the variants:
	dav: Add WebDAV support to server
	flv: Add FLV (Flash Video) streaming support to server
	mail: Add IMAP4/POP3 mail proxy support

 ssl: Add SSL (HTTPS) support to the server, and also to the mail 
 proxy if that is enabled
	status: Add /nginx_status support to the server

 perl5: Add perl support to the server directly within nginx and call 
 perl via SSI
	realip: Using nginx as a backend
	addition: Append text to pages
	substitution: Replace text in pages

 gzip_static: Avoids compressing the same file each time it is requested

 google_perftools: Enable Google Performance Tools profiling for workers

 upload: Enable Valery Kholodkov's upload module (http://grid.net.ru/nginx/upload.en.html)
	universal: Build for multiple architectures

Just using a few ?? to log to the trace.log file so it wouldn't even 
be seen by the calling script ...

I've noted in my todo list to extend the RSP API to be able to add/delete 
jobs (for now, the list is static, loaded from config file and cannot 
be accessed from RSP).

Scheduler is a standalone library. Cheyenne uses it to manage jobs 
defined in config file. UniServe will use it for example, to retry 
sending emails after x minutes.

Janko: look in the Cheyenne's ChangeLog file, that's where I document 
new stuff.

Direct link: http://code.google.com/p/cheyenne-server/source/browse/trunk/Cheyenne/changelog.txt

it was quite simple , I just joined two examples from their tutorials 
.. the SSL and the reverse proxy one .. I can give you the config 
file

how I use it: nginx get all the requests, if a file is not found 
it will proxy-reverse the request to cheyenne wich is configured 
with a on-status-code [404 trap.r] . trap.r check the url request 
and either load and respond with an rsp or send a 404

SVN r17 : big update, lot of code added mostly for the new embedded 
async Mail Transfer Agent (MTA)

FEAT: email async sending sub-system (MTA) added . 

FEAT: added two new functions for email support in RSP/CGI scripts: 
'send-email and 'email-info?
FEAT: added email sending demo form %www/email.rsp.

FEAT: Cheyenne's main process ID is now exported in /tmp/cheyenne.pid 
on start and deleted on quit. (All platforms except Windows).

FIX: fixed broken global words protection in RSP.r.
FIX: HTTP Date headers are now in UTC format.

FIX: "Reset Workers" menu wasn't working in service mode. Fixed now. 
(Thanks Will)

FIX: SVNr4 regression bug on system port for UNIX fixed. (Thanks 
Will)

FIX: multipart file uploading code refactored. Fixes many bugs in 
file uploading.

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.

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?

Two other issues in the 0.9.19 source:


1. INCLUDE and INCLUDE-FILE do not process paths identically. This 
is not mentioned in the docs.

2. INCLUDE won't include files in absolute paths. It simply changes 
the path to the current path which stores the RSP file that is currently 
being executed. I can't say that I have a fixed include directory 
somewhere at an absolute path. I don't see the purpose of altering 
the path like this.

I use include and include-file only to include files inside the web 
app ... never tried it otherwise

so, now app-init.r works for whatever reason. at least I can observe 
that changes to app-init.r only take into effect after restarting 
Cheyenne.

 => Webapp are persistent application in memory. RSP pages will be 
 reloaded on modification but %app-init.r can't without "restarting" 
 the whole application. As there's no clean/reliable way to completly 
 "unload" a Rebol app from a Rebol session, it requires to restart 
 the whole processes (all the worker background processes that may 
 have run your webapp). This can be achieved either by restarting 
 the whole server, or better, by using the "Restart Workers" feature 
 (documented in the changelog file). For unix: kill -USR1 <pid> (where 
 <pid> is Cheyenne main process id).

Graham: I'll release a new SVN version in a few hours after fixing 
known bugs/issues and rewritten netutils and file attachement stuff 
to get rid of Rebol non-conforming legacy code.

SVN r21 :


FEAT: log verbosity handling refactored, now more consistent across 
modules

FIX: email.r lib doesn't interfere anymore with other Rebol built-in 
schemes
FIX: bug in multipart/form-data decoding in RSP.r
FIX: email.rsp demo script now handles attached file correctly

I see the name of attached file once pick up using Chrome 3.0/Vista.

oh .. so you need to select a file first to see the field?

I can maybe add an option for that in the config file.

doesn't sound like a common case? Using FORM should be enough : 
<%= url-encode form %file %>

If it's for local server, file:// in href can work (see http://en.wikipedia.org/wiki/File_URI_scheme).

SVN r25

FEAT: encap paths are now in a separate file (%encap-paths.r)

In the www directory there's a demo file called email.rsp which you 
can use to test the MTA.  Change line 58 to your own from address.

in email.rsp, modify the lines at 43 to this

	if block? file: param/file [
		file/1: to-file file/1
		if file/2 [
			attempt [
				file/2: to-file file/2
			]
		]

And this works ...


myname: "Graham Chiu"
myemail: [gchiu-:-compkarori-:-com]
toemail: [dontspamme-:-gmail-:-com]
subject: "testing Cheyenne"
msg: "Yes, this i a message"
file: "encap-paths.r"
path-to-file: %/c/chesvn/Cheyenne/encap-paths.r



result: read/custom http://localhost:7900/email.rsp reduce compose/deep 
[ 'POST
	rejoin [
	"from=" (myname)
	"&from=" (myemail)
	"&to=" (toemail)
	"&subject=" (subject)
	"&msg=" (msg)
	"&file=" (file)
	"&file=" (path-to-file)
	]
]

because I use duplicate cgi names .. ie. from and file, they are 
turned into a block when processed

instead of 

if file/2 [

can try

if all [ file/2 not empty? file/2 ]

in email.rsp we have the following ..

	;-- check attach file and format it for send-email
	ten-mega: 10 * (2 ** 20)
	if block? file: param/file [
		file/1: to-file file/1
		

  either file? file/2 [	; check case where uploaded file has been streamed 
  on disk
			if any [not exists? file/2 ten-mega < size? file/2][
				print "Attached file not found or size above 10MB limit!"
				response/end
			]
			file/2: read/binary file/2
		]
		param/file: reduce [param/file]
	]

the either file? is missing the second conditional block .. I presume 
the first block checks to see if file/2 is of file type and the other 
type is binary

Also in chrome when you select a file, it just shows the filename 
... I wonder if and where it is storing the full path.

I'm just trying to do a file upload using RSP ... see http://rebol.wik.is/Cheyenne/Upload-file.rsp

What I'm getting however is this


request/content is [file "%/C/Cheyenne/incoming/oixaqcdg.tmp^M^/"]

and the file contains all the post variables and data

If the post data is over a certain size, it gets put in a temporary 
file that you can read.

I assumed it only put file data there and still captured the non 
file data into request/content

It even does it with non-file posts of sufficient size.

You can set the cutoff size in the config file.

I assumed it only put file data there and still captured the non 
file data into request/content

 => it requires to send data using "multipart/form-data" encoding.

Adding support for that shouldn't be difficult, but how to efficiently 
and securely manage the associations between user/pass and access 
rights? I'm not a big fan of .htaccess files scattered everywhere, 
and I'm not sure that cluttering the httpd.cfg file is much better. 
Maybe a separated centralized config file for user accesses? (I need 
to dig more on this topic before starting any implementation)

Getting this is in the latest Cheyenne when encapped

7-Oct-2009/12:12:03+13:00 : make object! [
    code: 500
    type: 'access
    id: 'cannot-open
    arg1: "/C/Rebol/UniServe/protocols/DNS.r"
    arg2: none
    arg3: none
    near: [do any [get-cache file file]]
    where: 'do-cache
]

Because you need to "refresh" the .encap.fs cache file before encapping 
by running Cheyenne in source mode at least once. This procedure 
has to be done each time the SET-CACHE spec block in %cheyenne.r 
is changed.

just thought I'd drop a little note that serious remark module work 
has begun.  I was trying some stuff before, but starting too wide 
and I wasn't able to get traction on the project.  now I'm just integrating 
the v2 remark parser into a mod.  


One cool thing that it will do out of the box, is handle statically 
parsed files. basically, you build .html files using remark dynamic 
tags, they are saved out in a cache dir and then the url-file function 
will redirect to the parsed file, if done, or will run the parser 
on it and then cache it.

Session: "On first request to a webapp resource." Hm... I'm not using 
a webapp, just a RSP file. Could this make any problems?

ID creation: My RSP file ends after the "startsession" for this case. 
So, only task here is to either re-use an existing ID or create a 
new one, that is used in all upcoming RSP calls. Hence, I think the 
logic is correct.

I've added your virtual domains definition to my httpd.cfg file, 
added a root-dir to domain.com, added :81 to the redirection URL, 
mapped both domain to localhost, changed domain.net's root-dir to 
%www/testapp and it works ok :

>> read http://www.domain.com:81
connecting to: www.domain.com
connecting to: www.domain.net
== {<html>
<head>
^-<title>Welcome to TestApp web application</title>...

I've also added port 81 to LISTEN directive in config file.

and also changed default file to %index.rsp.

BIND associates a mod handler with one or more file extensions. For 
example:


o bind SSI to [.shtml .shtm] : process those extensions through mod-ssi.

o bind php-fcgi to [.php .php3 .php4] : process those extensions 
thru  mod-fastcgi using a php backend.


The ID value used as first argument of BIND is just a hook used by 
the target mod to know which request it should process (as required 
by config file). See mod-ssi.r as an example.

BIND-EXTERN plays the same role for background processed modules. 
All BIND-EXTERN associations will be processed through mod-action. 
The first argument must match an external module file in %Cheyenne/handlers/ 
.

main => directive has to be in domain or webapp config block
global => directive has to be in global section of config file

loaded configuration file can be accessed from mod functions using 
this path: service/conf

Additionnaly, from mod functions, you can get your domain or webapp 
config block using req/cfg (you don't have to search in  the whole 
config file which part applies to the request, it's already done 
by Cheyenne).

I'm adding a lot of debug options within the config file directives 
right now... would be nice to be able to give an interactive face 
to those options  :-)

pekr, remark will be doing this by days end.  specifically, the file 
is parse once, until its saved out and cache is older than source. 
 once processed, normal cheyenne will continue with remark simply 
handling the url-to-file callback.

Pekr: it would not work that way, the CGI handler in worker process 
will try to DO the file.

No way currently, it's a pending issue. The policy to apply is not 
that simple, I may agree on halting when the server starts but how 
to handle the case when you reload config when the server is already 
up and running? I would prefer the server to keep running with the 
previous config file rather than halting. I'd like to handle the 
config error loading case in a consistent way if possible.

I have pretty steep requirements for the remark caching engine, but 
I'm gearing it towards long-term file caching, I was defering any 
RAM cache to a later date... funny how you pop up with such a thing 
right now :-)

(self modifying parse rules which adapt while parsing the file... 
a lot of fun :-)

(I am using AIDE for detecting file changes btw)

Try with ALIAS keyword. See ChangeLog file for more info (search 
for ALIAS).

alias "/show/" %www/mobispots.net/show.rsp -- gives me normal 404 
of cheyenne  (or any nonexistent file) 
<html><body><h1>404 Page not found</h1></body></html>

alias "/show/" %show.rsp -- gives me 
#[object! [
    code: 502
    type: access
    id: cannot-open

    arg1: %/D/devel/cheyenne0919/www/mobispots.net/www/mobispots.net/
    arg2: #[none]
    arg3: #[none]
    near: [change-dir first splitted: split-path file]
    where: #[none]
]]

I suspect %show.rsp is the correct one (which gives that error) , 
because for any nonexistent file likse %show.rspaaa I get 404 so 
I suspect %www/mobispots.net/show.rsp is also not correct to use

Does Cheyenne produce error log? I can see directory called /log, 
but I can see only default-access file in-there ...

hi, I have a problem about sessions, when I start a session, then 
end it, then restart it, session/active? return false if the file 
is not in same location with the file which is started the session.

and option to globablly in conf file set compression off maybe

-- the .so file missing was another problem but now I saw it still 
works like that. Now that .so it there.. after I restart, if I go 
on webapp af virtual host A first then I see at B that it runs A's 
app-init.r , if I go to the v.h. B birst , then A will report errors 
because it will run B's app-init

Hmm, I think that the way I've used "webapps" in my previous msg 
is confusing, I was referring to a "web application" built using 
RSP scripts not the "webapp" keyword used in config file. A web application 
(along with its app-init.r file) is unique. OTOH, a webapp config 
is per virtual host.

Janko, about the app-init code you've uploaded, just a side note 
: you're loading a *lot* of code (libs?) on each RSP request, this 
is surely slowing down each request a lot. You should be loading 
all these libs in 'on-application-start instead. (btw, "simpauth.r" 
is loaded twice)


About local testing, you can use virtual hosts locally too in Windows 
easily. Just add them to C:\Windows\System32\drivers\etc\hosts file. 
Add them all after 127.0.0.1 (but do not use exactly the same domain 
name as the remote ones or you won't be able to access them anymore). 
I use shortcuts of my real domains for locals : softinnov.org => 
si.org, curecode.org => cc.org, etc...

@Doc: 

- I am not totally sure I correctly understand what you mean about 
webapp. I will need to process and try it some more.

- About code loading on on-page-start : yes I know of that, I am 
using it as dev setup so I know latest code is reloaded each pageload. 
I intend to set it on     on-application start when fully in production 
(But I have to admit the server is bgehaving really fast even with 
this setup all along)
- good catch, I will remove one simpauth.r

- I am aware of hosts file, but so far decided to edit the cfg file 
each time I switch ... which is in retrospect getting a little tiresome 
with more and more apps so I should think of  some naming convention 
for getting to all domains local and do it that way yes

- great for multi instance support . I also already ported site-assistant 
to 0919. it was much less work than I thought.. mostly just few things 
like do -> do/global and some 3 other tricks (no really aplication 
level changes were needed)

I've got this really odd situation ... I have Cheyenne and the rebol 
micro web server both running.  Cheyenne is on 8002, and MWS on 8001.
Both share the www directory.

at times I access a file and I get a 404 from Cheyenne but the MWS 
can find the file!

SVN: Can someone give me a short note how to best get the SVN version 
into a "production environment"? Is it one file I can just run on 
the server? Or do I need to build it myself somehow?

Currently, your web socket URL must point to an existing RSP script 
(or a path that translates to a RSP file). The included %ws.rsp script 
is just a simple echo service.

Graham: you should check if your server is reachable on this URL 
: http://localhost/ws.rsp(it should if you're using the config file 
from SVN). 


Web Control Panel : yes, it's easier with web sockets than with COMET 
approach, but it's not a show stopper anyway.

Mail server : it could make it easier if you're using a client supporting 
web sockets.

Not using the default config .. but I get this

26/12-10:17:23.838-[RSP] ##RSP Script Error: 

	URL  = /ws.rsp
	File = www/ws.rsp

	** Script Error : Invalid path value: data 
	** Where: rsp-script 
	** Near:  [prin request/content/data] 


Request  = make object! [

    headers: [Host "localhost:8000" Connection "keep-alive" User-Agent 
    {Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 
    (KHTML, like Gecko) Chrome/4.0.249.43 Safari/532.5} Accept {application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5} 
    Accept-Encoding "gzip,deflate" Accept-Language "en-GB,en-US;q=0.8,en;q=0.6" 
    Accept-Charset "ISO-8859-1,utf-8;q=0.7,*;q=0.3"]
    status-line: #{474554202F77732E72737020485454502F312E310D0A}
    method: 'GET
    url: "/ws.rsp"
    content: none
    path: "/"
    target: "ws.rsp"
    arg: none
    ext: '.rsp
    version: none
    file: %www/ws.rsp
    script-name: none
    ws?: none
]

If you're not running on port 80, then you need to modify the ws.html 
file and add the port number in the ws://localhost part ...

you require my updated ws.rsp file.. see above.

the connection is open, but RSP is stateless

 If you want to make it stateful, just store the data in session, 
 file, database, whatever...Most of RSP API is still working with 
 web sockets (response object methods will have no effect).

Pekr: no problem. Cheyenne is one of the application that would benefit 
the most from threads.


IPC between processes can't compare to shared memory between threads. 
With processes, you need to serialize values, transfer them (multiple 
memory copies or worth using a disk file), then LOAD them back. With 
shared memory, you just pass a memory reference to the value and 
you ensure (using a sync mechanism) that no concurrent writes occur 
on that value. It's at least a magnitude faster and uses so much 
less memory.

I forgot to commit one file.

Just fooling around.. there's some interesting behviour here... 

changed the on-timer function in  ws-test-app.r file to... 

	on-timer: does [								
		foreach port clients [						 
			out: do %test.r
			send/with out  port				 
		]										 
	]


.. and created a test.r file in Cheyenne's root thus.. 

rebol []

a: "42"
b: "43"

out1: rejoin ["OUT1: " b]
out2: rejoin ["out2: " a]
out1

due to a file lock on the application ... maintained by whatever 
...

PHP: quite stable as long as you don't do live %httpd.cfg file reload 
(mess up PHP processes).

do-task in RSP : no, UniServe's model is : one unique dispatcher 
process, one or many worker process.

Timers: no, they require an event loop, worker processes can't have 
one because they are supposed to work in a request/response model.

No, the bindind between the URL (/chat.rsp) and the web socket app 
(chat) is done in the httpd.cfg file with the 'socket-app keyword.

I found this example of doing the file upload in cheyenne but I don't 
understand it fully. http://rebol.wik.is/Cheyenne/Upload-file.rsp

aha, I see it now..


btw: I noticed one thing.. when I uploaded file request/conetnt keys 
returned to strings from words .. so I had to do req: request/content 
forskip req 2 [ change req to-word first req ]  to fix them back

You can also copy/paste the latest 'decode-multipart function in 
your 0.9.19 RSP.r file, modifications are minor and not dependent 
on other parts.

I am using 0.9.19, no problem just wanted to mention. 


@Graham: can I ask why are you doing this (checking for file OR data 
in request/content): 
either file? filedata/2 [ 

 write/binary join get-user-dir filename read/binary join incomingdir 
 filedata/2
] [ 
	if filedata/2 [
		write/binary join savedir filename filedata/2
	]
]


I imagine if file is bigger it get's saved and you copy it. But how 
can you then determine the incoming/pwd is this some cheyenne default?

cause there is a default directory for all incoming file data ...

All in all doc, cheyenne sockets are very impressive. 
Couple of suggestions.. 

- Have a folder specifically for socket-apps that automatically get 
loaded into the http.conf file.. 

- Create a connection through PHP (if possible.. otherwise can just 
proxy, but adds lag)

SVN r59 : experimental mod-upload released.  This new mod adds server-side 
API for querying realtime progress info on uploaded files. See the 
demo : http://localhost/upload.html(not commented yet).

Current restrictions:
- works only when posting one file at a time in a given <form>.

- can't make it work for IE (IE seems to have an issue with setTimeout( 
) method).

If you're testing the upload demo locally, be sure to pick a file 
big enough (at least 10 Mbps). Don't worry about uploaded files, 
the target script (show.rsp) doesn't save them, so the server's copy 
will be deleted as soon as the upload is finished.

After updating the SVN, I get a 

 id: 'cannot-open
    arg1: "/c/websock2/Cheyenne/mods/mod-upload.r"

and the file is not there.

should have some default error trapping for socket-apps in the http.cfg 
file, no? One typo brings the whole server down.

Typos errors in config file should be caught, what kind of typo was 
that?