World: r3wp

Untested, but that should work.

I want server to "flush" responses as fast as it can and client render 
them without compressing/decompressing ... I might be wrong and I 
will test if there are any differences, but I had bad exper. when 
we tried to minimize and *gzip* js libs (like they usually) do the 
website latency actually became much worse with gzip than without

Unless your server CPU is heavily loaded or you're serving only very 
small files, having compression on usually improves performances. 
You should benchmark it first before turning it off.


Btw, currently, compression in Cheyenne only applies to RSP scripts 
output, it's not yet available for static files.

is there an existing mechanism for basic authentication?

can users access a web app using basic authentication .. or do we 
have to write that ourselves?

No builtin support for basic auth. You need to provide your own code. 
'on-page-start would be a good place to put that kind of filter.

ok

Why do you need BA in this case instead of usual login form?

Just curious.

PDF has an image field

it can grab the image from a url

I want to use an image for a signature

so I need to get it from a password protected part of the website

so I need to authenticate inside the url

I can't place the signature image in public

same for accessing fax services

need to authenticate in the same url that sending the fax

I see. So basically, you just have to check for the correct credentials 
in HTTP headers, else you just need to send back a 401 status code 
+ auth header IIRC.

Yes, Acrobat has no way of authenticating against a web server :)

Is that an adequate reason ? :)

I was thinking about a PDF-related restriction, just wanted to be 
sure. :-)

Graham, I think using the image link rather than embedding the image 
does not really protect the image, and requiring an extra web access 
to get the signature image is more prone to failure,

as well as being an alternative way of picking up the image (intercepting 
the web traffic is easy).

I've found a way to merge the signature image with the pdf on the 
server ... but the pdf still needs to be accessed by acrobat

(What needs to be accessed by Acrobat?) Sorry, I'm not quite clear 
what the scenario is.

there is a thing called an xfdf file ... when acrobat reads such 
a file, it goes to fetch the pdf in the href spec in that xfdf file.

Oh, I think I understand:

Before:
	Acrobat opens xfdf -> pdf -> image
Now:
	Acrobat opens xfdf -> pdf [image]


So before, the client Acrobat opens the xfdf file, which links to 
the pdf on your website, which links to the signature image on your 
website.

Because of the signature image, authentication is required when linking 
to the image, and Acroforms used in the PDF limits this to Basic 
Authentication.


Now that you've figured out how to embed the image in the pdf, the 
client Acrobat opens the xfdf file, which links to the pdf on your 
website, which has the signature image embedded already. Because 
of the signature image, authentication is required, but because the 
image is embedded in the pdf container, authentication is required 
when linking to pdf. (And I presume still limited to BA?)

Hello everybody!

I''m new with Rebol, I hav a small server (VIA M-EPIA) and 512Mb 
of RAM and linux;
Is better Apache or Cheyen? 

I need only PHP, MySQL and linux script (image magick and ffmpeg), 
what are your opinions?

Both are very good, but Cheyenne may be much easier for you.

Anton, yes :)

I got it... (amazing! :)

http://www.geocities.com/cheyenne_language/

Could be useful if your looking for names for components.  ;-)

I noticed that www.cheyenne.com goes to CA's website.  This looks 
like a marketing stradegy but does that mean the same Cheyenne as 
Doc's awesome product here?

If so, it must be flattering.

Thanks for the link Paul, I'll check that site next time I need a 
name! :-)

Re MaxV: If you plan to use *only* PHP and MySQL, I think that Apache 
is a more logical choice. Cheyenne is built mainly for web application 
programming in REBOL. Support for PHP is here only to avoid installing 
another web server if you already use Cheyenne (for REBOL apps).

How do you handle file uploads in Cheyenne RSP? I have a need to 
upload a file regularly. Post is fine - I don't need put.

Two ways.  If it is small enough, it is saved in the session, otherwise 
it is saved to a temp file which is accessed by the session variable.

so if request/posted is binary, then it's what was posted, but if 
it's a string, it points to a temporary file.

The uploaded file is written on disk if it's size exceed 100'000 
bytes. You can change this default threshold value by using the 'post-mem-limit 
 keyword in virtual host configuration options (in %httpd.cfg).


Cheyenne can handle file uploads up to 2GB size with no noticeable 
impact on memory usage.


The temporary file is stored in an %incoming/ folder at Cheyenne's 
root. The file is deleted once the response is sent to the client, 
so in order to keep it, you have to rename it or copy it elsewhere.


You can use the %show.rsp sample script as target of a POST action 
to test it.

(...its size exceeds...)

If you want to access a web app from Rebol

page: open login-url ; a rsp session is sent to you
page/locals/headers/set-cookie contains the cookie

page: read/custom login-url compose/deep [ POST (auth) [ cookie: 
(cookie)]] ; where auth is your authentication string eg. "login=user&pass=mypassword"
you are now authenticated
and if you now what to access a page in the web app

page: read/custom web-app-url compose/deep [ GET "" [ cookie: (cookie)]]


where you need to use my modified http protocol that allows you to 
send cookies with read/custom

If the file exceeds the post-mem-limit value I get an empty response 
error.
Error 324 (net::ERR_EMPTY_RESPONSE): Unknown error.

No file gets written to the %incoming/ directory, though that directory 
gets created.

I'm going to increase the post-mem-limit for now, but it would really 
help if I had the external file so I could have MySQL read it.

what build?

and did you look at the logs?
run cheyenne in verbose mode?

The recent release build. Nothing shows up in the logs. I'll try 
verbose mode.

2/4-22:54:04.266-## Error in [uniserve] : On-received call failed 
with error: make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'insert
    arg2: 'series
    arg3: [series! port! bitset!]
    near: [insert/part tmp/port s skip e]
    where: 'process-bounded-content
] !

This is in -vv mode. Should I post the rest of the logs forr that 
request?