r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Cheyenne] Discussions about the Cheyenne Web Server

Graham
30-Sep-2009
[6125x2]
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
BrianH
30-Sep-2009
[6127]
If the post data is over a certain size, it gets put in a temporary 
file that you can read.
Graham
30-Sep-2009
[6128]
I assumed it only put file data there and still captured the non 
file data into request/content
BrianH
30-Sep-2009
[6129]
It even does it with non-file posts of sufficient size.
Graham
30-Sep-2009
[6130]
oh well ....
BrianH
30-Sep-2009
[6131]
You can set the cutoff size in the config file.
Graham
30-Sep-2009
[6132x2]
I'm going to have to load it back into memory in my rsp script anyway
in httpd.cfg ?
BrianH
30-Sep-2009
[6134]
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.
Graham
30-Sep-2009
[6135]
do you know what the setting is?
BrianH
30-Sep-2009
[6136]
I'd have to look it up. Give me a sec.
Graham
30-Sep-2009
[6137]
data: decode-cgi dehex read/binary %temp.tmp ....
BrianH
30-Sep-2009
[6138]
post-mem-limit, in web-app, in bytes.
Graham
30-Sep-2009
[6139]
under globals?
BrianH
30-Sep-2009
[6140x3]
Under web-app (at least that's where I used it).
sorry, webapp
Check both.
Dockimbel
30-Sep-2009
[6143x2]
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.
Graham
30-Sep-2009
[6145]
what's the default limit ??
Dockimbel
30-Sep-2009
[6146]
100'000 bytes IIRC
Graham
30-Sep-2009
[6147x6]
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
Graham
2-Oct-2009
[6153]
Seems I continue to have the need for basic authentication to allow 
3rd party resources access pages.
Dockimbel
3-Oct-2009
[6154]
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)
Graham
3-Oct-2009
[6155]
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
Henrik
5-Oct-2009
[6156]
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?
Dockimbel
5-Oct-2009
[6157]
Well it depends on what you mean precisely with "user login system". 
Sessions associate a context (in the general sense) holding data 
with a remote web browser session. The AUTH config keyword controls 
whether access to webapps resources requires a "login" process or 
not. The login state is reflected in a built-in special word in RSP's 
sessions (session/content/login?). LOGIN? is also settable, so you 
can avoid using AUTH and build your own login system (you'll have 
to overload the 'on-page-start handler to restrict accesses).
Graham
5-Oct-2009
[6158]
Is this something we can use ? http://babelserver.org/rebol/memcached/
Dockimbel
5-Oct-2009
[6159]
You need to setup a memcached server first I guess. Will has implemented 
something similar as a cheyenne mod. I may integrate such feature 
inside Cheyenne in future.
Henrik
5-Oct-2009
[6160]
Doc, thanks.

What I need to do is basically the whole package:

Sessions, which Cheyenne can do.
Login process with authentication. AUTH config, perhaps.
Log out process, also possible.
User adding and removal process. This needs to be added.
Privilege usage and management. Also added separately.

I'll have a closer look at the built-in AUTH config keyword.
Will
5-Oct-2009
[6161]
It's a uniserve service with an rsp interfaces, works pretty well, 
if something takes more than 1 millisecond to execute, better cache 
and reuse 8)
interface is simple:

.cache 'pool-name 'variable-name 'valid-time-in-seconds [code to 
execute]
one refinement, /set , will force update cache
Graham
5-Oct-2009
[6162]
Available to a number of servers?
Will
6-Oct-2009
[6163]
if you want so, just uncomment or change this line in UniServe/services/cache.r 
:
if client/remote-ip <> 127.0.0.1 [close-client]
Graham
6-Oct-2009
[6164x3]
I have the latest svn checkout ... I don't see a cache.r  !
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
]
Why should it be looking for dns.r when it should be inside the cache?
Dockimbel
7-Oct-2009
[6167]
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.
Graham
13-Oct-2009
[6168]
I use Cheyenne as a helper application.  Now my main application 
occasionally has to access files from S3 but synchronously.  Since 
the s3 tools don't have async versions, does it make sense to perhaps 
to use RSP to download the S3 files I need.  I can call RSP async 
from my app.
Dockimbel
13-Oct-2009
[6169]
Could you just use UniServe with async HTTP protocol? (I can put 
it online, it's not part of Cheyenne package)
Robert
13-Oct-2009
[6170x5]
Seems that I have a problem with session handling in that I don't 
get a new session when I expect it.
I use session/id as a filename to store some temporary data between 
requests. But it seems either that session/id is not that renadom 
or that a session somehow survives a long time.
How is a session managed? When is it created and when is it destoryed?
It seems that I somehow get back an old session/id from someone else 
even I just opened my browser and loaded a page.


This problem shows in my REST shopping cart in that I get a shopping 
cart from someone else.
The code handling this looks like:

; GET
startsession
 [
  unless session/active? [ session/start]

  if load-cart session/id [show-cart]
]

; POST
addtocart
 [
  ; do we have a browser session?
  either session/active? [
     load-cart session/id
     ....