World: r3wp

use whatever port your Cheyenne is running on

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

And this means order is important

instead of 

if file/2 [

can try

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

Nice idea! A REST-like interface to Cheyenne's MTA using the demo 
email form. :-)

yeah ... like FormMail.pl ... all spammers invited :)

I like the fact that I can pass a file! so that I don't have to figure 
out how to do a multipart upload to the mail.rsp script.

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

I guess change the 'either to an 'if

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

How can I stop the browser from caching the response/buffer ?  I 
set the response butter and content type, but the browser seems to 
be caching the buffer.

set the headers I guess

see the header I set in 'reform-headers here : http://code.google.com/p/cheyenne-server/source/browse/trunk/Cheyenne/mods/mod-action.r#

headers

SVN r30 :


FEAT: MTA engine refactored, jobs are split in sub-tasks allowing 
more reliable and cleaner code.
FEAT: Default SMTP delay reduced to 5mn.

FEAT: MTA queue can now be saved on disk when server is restarted 
(persist [mail-queue])

FEAT: added native DNS async wrapper for UniServe (protocols/DNS.r)

FEAT: replaced blocking DNS calls for MX domain resolution by async 
DNS calls.

FEAT: 'on-mx event in DIG protocol now returns a block of all the 
declared MX.

FEAT: now all MX will be tried in right order by the MTA if connexion 
fails.
FEAT: improved SMTP logs by prefixing with a SMTP session ID.

FEAT: upload data in HTTPd limited to 2GB (max supported by integer! 
type)

FEAT: 'email-info? RSP function return data format improved (see 
email.rsp header)

FIX: email.rsp minor bugs fixed and From: field added.
FIX: minor fixes in email.r library.

FIX: now uni-engine's logging level is also set by 'set-verbose function.

Due to heavy changes in the MTA engine, regressions can happen. All 
my tests are working ok so far.

Btw, you can see a nicely formatted diff of all the changes here 
: http://code.google.com/p/cheyenne-server/source/detail?r=30
(click on [+] to see the changes)

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.

oh well ....

You can set the cutoff size in the config file.

I'm going to have to load it back into memory in my rsp script anyway

in httpd.cfg ?

Yes. It's probably to cut down on interprocess communication between 
the host and worker processes. The RSP is processed in a different 
process than the web server process.

do you know what the setting is?

I'd have to look it up. Give me a sec.

data: decode-cgi dehex read/binary %temp.tmp ....

post-mem-limit, in web-app, in bytes.

under globals?

Under web-app (at least that's where I used it).

sorry, webapp

Check both.

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.

BrianH answered correctly, 'post-mem-limit allows you to set the 
maximum size of incoming data stored in memory. If that threshold 
is reached, all request content data is flushed on disk to avoid 
memory starvation attacks.

what's the default limit ??

100'000 bytes IIRC

ok.

I have a need for users to "sign" PDFs using a tablet ...

Jarnal is an open source Java app that can ink on PDFs and save them 
back to the server by posting the PDF with the annotations to a cgi 
script.

It can also save the first page of the PDF as a Jpg, and interestingly 
the PDFs are about 12kb in size but the Jpegs are about 150kbs

but the reduced size advantage of the pdf is disadvantaged by the 
time it takes to recreate the PDF .. ie. saving it as a jpeg is faster.

though consumes more network resources

Seems I continue to have the need for basic authentication to allow 
3rd party resources access pages.

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)

Dunno .. but at present I am putting files into public to allow 3rd 
party apps to access them ... and using very long filenames to obscure 
them

I'm about to build a user login system, but I would like to know 
if it's a good idea to make this a public project so others can follow 
and contribute? Would it be a good idea to include it in Cheyenne? 
I don't intend to use MySQL for it as the rest of my site isn't DB 
driven.


I've not done anything yet, so I also need to know, what Cheyenne 
can already do in this area, to avoid duplicating functionality. 
Can I completely rely on the session context, or are there crucial 
parts missing?