• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

AltME groups: search

Help · search scripts · search articles · search mailing list

results summary

worldhits
r4wp8
r3wp25
total:33

results window for this page: [start: 1 end: 33]

world-name: r4wp

Group: Rebol School ... REBOL School [web-public]
JohnM:
16-May-2012
Sunanda: Thanks again for issuing the World invitation. Everyone 
thanks for the continuing help.


I have read the cited document, but it just leaves me with more questions.

Is the following literal?

cgi-string: read-cgi
cgi-block: decode-cgi cgi-string
cgi-obj: make object! cgi-block 


 That is to say should I type exactly that? Or is cgi-string for example 
 a theoretical variable assignment that I could call anything? Are 
 they all proper commands, or is any part of that just for example 
 purposes?  I am thinking I should copy and paste it verbatium. I 
 am also thinking I mispelt verbatum.


 I am stuck with GET. Does this mean I can leave out some code that 
 makes up for  not knowing if the original data is POST vs GET? These 
 are hypothetical questions for better long term learning. I for now 
 will go with the idea that everything is as straight fowarrd as it 
 seems. I know that my GET stream will have "trnEmailAddress" in it 
 which is a field that will contains an email address.


 So will the following  generate a random number, extract the address 
 and email the same random number to that email address?

token: random/seed now/percise

cgi-string: read-cgi
cgi-block: decode-cgi cgi-string
cgi-obj: make object! cgi-block 


send trnEmailAddress rejoin [ "Thank you. Your number is" token "." 
]


 Graham: Thank you for the extra info on GUID, but Windows is not 
 involved here. I realize that random number generating really isn't 
 unless you have a monkey throwing darts at a numbered board. Regardless 
 extra effort to 
make a number unique is useful and your advice appreciated. 


 I do not think the corner cases will come up and the people who control 
 the original form assured me that web page issues warnings if the 
 form is not filled out correct which should help. I do realize that 
 people are idiots, systems are not fool proof, etc. What I am saying 
 is my basic needs are basic and I should be OK so I am not fretting 
 over those examples. It is great though to know the solutions are 
 out there when I need them.

 Tahnks.
Sunanda:
16-May-2012
Yes, the names of the words are arbitrary. -- you can chose your 
own names.


Whether the data came in via GET or POST makes no difference if you 
issue the READ-CGI just once.

If the CGI string was yadda.com?email=[me-:-test-:-com]&token=0
then the cgi-obj will look like this:
    make object! [
    email: "[me-:-test-:-com]"
    token: "0"
]

Note the values are strings, so you need to convert the email value 
to an email! datatype:

  send to-email cgi-obj/email rejoin [ "Thank you. Your number is" 
  cgi-obj/token "." ]
GrahamC:
16-May-2012
John you have to seed the generator first and then generate your 
number
And you can dispense with the cgi-string by 

cg-block: make object! decode-cgi read-cgi
Endo:
17-May-2012
Here is an example:

cgi-obj: construct decode-cgi read-cgi

;check the input
all [
	in cgi-obj 'email
	trnEmailAddress: to-email trim form cgi-obj/email
	not empty? trnEmailAddress
] [
	;evrything seems ok

 send trnEmailAddress reform ["Thank you. Your number is" token "."]
	quit
]
print "Error!"
Group: Databases ... group to discuss various database issues and drivers [web-public]
Pekr:
11-Nov-2012
please use:

values: decode-cgi read-cgi

then you will get block of values IIRC
Pekr:
11-Nov-2012
so use:

values: decode-cgi read-cgi
result: construct values

insert db ["insert into data1(oneone) values(?)" result/oneone]
afsanehsamim:
11-Nov-2012
i am using the first one ... can i use codes which you mensioned 
in above ?  values: decode-cgi read-cgi
result: construct values

insert db ["insert into data1(oneone) values(?)" result/oneone]
Pekr:
12-Nov-2012
Create 2 files. Call the first one e.g. cgi-test.html, and upload 
it to your server. The only thing you have to change is the link 
to your .cgi script in there:

<HTML>
<TITLE>Simple Web Form</TITLE>
<BODY>
<b>Simple Web Form</b><p>
<FORM ACTION="http://www.xidys.com/cgi-bin/cgi-test.cgi">
<INPUT TYPE="TEXT" NAME="Field" SIZE="25"><BR>
<INPUT TYPE="SUBMIT" NAME="Submit" VALUE="Submit">
</FORM>
</BODY>
</HTML>



Create a second file, called cgi-test.cgi (it has to align to how 
you name it in the above source file). Upload it to your cgi working 
directory. Remember to change the first line to contain the path, 
where your REBOL executable is placed:

#!/usr/local/bin/rebcmd -sqc

REBOL []

print join "Content-type: text/plain" newline
start: now/time/precise

submitted: decode-cgi read-cgi
values: construct submitted

prin "Submitted: " print mold submitted
prin "values: " print mold values
prin "values/field: " print mold values/field

print now/time/precise - start
print newline
 

Now go to your URL, and try to submit some values. You can test it 
on my site at: http://www.xidys.com/cgi-test.html

world-name: r3wp

Group: Core ... Discuss core issues [web-public]
Pekr:
27-Dec-2005
what is the problem with post? as for cgi, I use read-cgi as in newer 
cores ... works so far ...
Terry:
27-Dec-2005
where do you put read-cgi in the forever loop?
Pekr:
27-Dec-2005
read-cgi ...
Volker:
27-Dec-2005
read-cgi: func [/local data len] [
    either system/options/cgi/request-method = "POST" [

        set-modes system/ports/input [lines: false binary: true no-wait: 
        false]
        len: to-integer system/options/cgi/content-length
        data: to-string copy/part system/ports/input len
    ] [
        data: system/options/cgi/query-string
    ]
    data
 ]
Group: CGI ... web server issues [web-public]
Brett:
2-Mar-2005
For anyone interested in getting Carl's blogger script (blog.r) to 
work under Cal's rebol webserver (webserv.r):

(1) Cal''s script passes Carl's script a tcp connection and set's 
no-wait on this connection.  Carl's script doesn't like that.

(2) So I modified the post section of read-cgi in Carl's script as 
follows:

     set-modes system/ports/input [binary: yes lines: no no-wait: false]

     if integer? content-length: attempt [to integer! system/options/cgi/Content-Length] 
     [
	        data: copy/part system/ports/input content-length
	    ]

 ; which is based on some code Gabriele suggested a long while ago

(3) Also, Cal's script was performing poorly for me (even on static 
files) until I modified a wait statement from [listen 0] to [listen 
0.01].

So far these two changes make the combination work quite fast for 
me.
Volker:
22-Apr-2005
read-cgi: func [/local data len] [
       either system/options/cgi/request-method = "POST" [
               len: to-integer system/options/cgi/content-length
               data: to-string copy/part system/ports/input len
       ] [
               data: system/options/cgi/query-string
       ]
       data
]
Volker:
22-Apr-2005
and for your script:
print "Content-type: text/html^/" 
read-cgi: ...
args: decode-cgi read-cgi 
template: {
 <html><body> <pre> <% mold args %> </pre> </body></html>
}
print build-markup template
Sunanda:
5-Jun-2005
It's fairly straigt-foward (I think!).


.......If you have no multi-part data, then just used the "standard" 
read-cgi  -- but remember that on some platforms no input returns 
"" while on others it returns none
http://www.rebol.com/docs/words/wread-io.html


.....If you have multi-part data (say an uploaded file), then use 
Andreas' decode-multipart-form script:

 http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlKVSQ


.....If the form could have both or neither (ie there may or may 
not be a file uploaded), then each of the above solutions will fail 
(Carl's when there is. and Andreas's when there isn't)....So wrap 
the full code in a few attempts to handle that.
Volker:
5-Jun-2005
(AFAIK:) The browser submits what read-cgi reads. Post means: give 
script all data in stdin (system/ports/input). Thats for lots of 
data, when you post something. Get means, give data in url. Thats 
for getting data, the query is only short (and typable in urlbar). 
So read-cgi write that in a file and read it in an editor.
Volker:
5-Jun-2005
Andreas script does the same (thanks for link sunanda ;) 

You find there a 'read-post-data, thats read-cgi with another name. 
and that is used in 'decode-multipart-form-data.
François:
25-Jul-2005
read-cgi: func [
        "Read CGI form data from GET or POST."
        /local data buf
    ][

        if found? find/any system/options/cgi/request-method "POST*" [
            data: make string! 1020
            buffer: make string! 16380

            while [positive? read-io system/ports/input buffer 16380][
                append data buffer
                clear buffer
            ]
            return data
        ]

        if found? find/any system/options/cgi/request-method "GET*" [
            return system/options/cgi/query-string
        ]
        test-data ; if in test mode
    ]
Sunanda:
15-Nov-2005
You are using "post" -- that needs some extra processing compared 
to get.

See: http://www.rebol.com/docs/cgi2.html-- loook for read-cgi function
Pekr:
5-Dec-2005
2) how secure is following? 

str: copy ""
result: decode-cgi read-cgi

foreach [word valu] result [append str join "" [word ":    " value 
newline]


I mean - above block in 'join statement is reduced - is it secure?
Pekr:
5-Dec-2005
3) I have older version of rebcmd from linux sdk I bought. But it 
did not used 'read-cgi at that time (well, here we are with SDK coming 
late ;-) My question is - I uploaded rebol core into cgi-bin directory:
a) is it desirable aproach or should it be avoided?

b) how do I assure, that if I ftp rebol executable to cgi-bin dir, 
to have sufficient right of the target directory, so that it could 
be run?
Volker:
5-Dec-2005
I think url are passed in another way. in read-cgi is "system/options/cgi/query-string"
Louis:
10-May-2006
What is wrong with this script?

#!/home/daysprin/public_html/cgi-bin/rebol -cs
REBOL []
print "Content-type: text/html^/"

html: make string! 2000
emit: func [data] [repend html data]

read-cgi: func [
    ;Read CGI data. Return data as string or NONE.
    /local data buffer
][
    switch system/options/cgi/request-method [
        "POST" [
            data: make string! 1020
            buffer: make string! 16380

            while [positive? read-io system/ports/input buffer 16380][
                append data buffer
                clear buffer
            ]
        ]
        "GET" [data: system/options/cgi/query-string]
    ]
    data
    probe data
]

cgi-data: decode-cgi read-cgi
print cgi-data
write/append %nr.txt reform [
	now/date
	system/options/cgi/remote-addr
	mold cgi-data
	newline
]
Group: !REBOL3-OLD1 ... [web-public]
Pekr:
8-Oct-2009
What do you think about CGI module or any such special modules - 
would you make some of them default part of the distro, just modularised? 
Or you want them to be external? I think that CGI is basic functionality, 
which should be included in default distro, just with better support 
for sessions, not just decode-cgi, read-cgi ...
Group: !Cheyenne ... Discussions about the Cheyenne Web Server [web-public]
Dockimbel:
31-Jan-2009
New Cheyenne 0.9.19 beta version available for testing at : http://cheyenne-server.org/tmp/cheyenne-r0919.zip


Tested only on Windows  (my Linux image network has currently some 
issues).

ChangeLog (diff-ed from last test version) :


 o RSP: an HTTP redirection in 'on-page-start won't evaluate the page 
 script anymore.
	

 o CGI: mezz function READ-CGI now patched to be compatible with Cheyenne. 
 That's
	  the right way of reading POST data in REBOL CGI scripts.
	  
	o RSP: fixed a bug in session/add when setting a block! value.
	

 o Task-handler: fixed a network error on first packet read (high 
 load + fast hardware).
	

 o Task-handler: TCP keepalive mode activated (test workaround half-closed 
 connections).
	
	o Task-master: 
			o 'no-delay mode removed and replaced by 'keep-alive mode

   o now forks a new process as soon as one dies (not waiting for a 
   new request)

   o fix a long standing bug in queued job module name mismatching (can 
   happen under extreme load)
			o minor code cleanup
	

 o Uniserve: 'no-delay TCP network mode now switched off for all connections. 
 Fixes a

   stability issue on Vista and probably on UNIX with very high load.


 o RSP: fix a bug in 'decode-multipart when there's no file received.
	

 o UniServe: new logger service. Now all info or error logs, and debug 
 messages from

   CGI/RSP scripts are written in %trace.log. Additionnaly, you can 
   now log messages
	  using :
	  
	  		- debug/print msg 	; msg [string!]
	  		- debug/probe value 	; any mold-able value
	  		- ?? word		; works like REBOL's '?? function
	  		- ? msg		; alias for debug/print
	  

 o RSP: in debug mode, page generation time and SQL queries stats 
 now added at bottom
	  of pages.
	  
	o RSP: error in events from %app-init.r now logged.
	

 o RSP: fix a rare RSP freezing issue when an error occurs in %RSP.r 
 (for example, by
	  a user script that breaks RSP sandbox).
	  

 o RSP: sanboxing now protects from Exit/Return/Break calls made outside 
 of a
	  function context.
	  
	o RSP: %misc/rsp-init.r file removed.
	

 o RSP/CGI: New config keyword added in global sections : 'worker-libs. 
 It lists the

   librairies to load when a worker process is started. An optional 
   'on-quit section can

   be added to call cleanup code when the process quits. Examples :
	  
	  		worker-libs [
				%libs/mysql-protocols.r
				...
			]
		or	
			worker-libs [
				%libs/mysql-protocols.r
				...
				on-quit [
					%/libs/free-resources.r
				]
			]
	

 o Task-master: now you can reset all worker processes without stopping 
 Cheyenne. This

   is usefull when you need to force non-RSP/CGI files reload (helper 
   scripts, 3rd party
	  librairies,...). 
	  
	  	Usage:
	
			Windows : tray icon -> Reset Workers
		

   UNIX : kill -s USR1 <pid>	(<pid> is Cheyenne's main process ID)
	 
	 

  o Added a -w command line option to set the worker processes number. 
	 
	   	Usage:
	   
	  		$ cheyenne -w <n>		(n [integer!] : CGI/RSP process number)
	   

    Use -w 0 to help debug CGI/RSP code by resetting worker processes 
    after each request.
	   (it's like calling "Reset workers" after each request).
NickA:
17-Jan-2010
Graham,  I've used this code to obtain get/post data in Cheyenne:

REBOL [title: "sitebuilder" file: %sitebuilder.cgi]
print "content-type: text/html^/"
print [<HTML><HEAD><TITLE>"Sitebuilder"</TITLE></HEAD><BODY>]
either system/options/cgi/request-method = "POST" [
    submitted-bin: make string! input
] [
    submitted-bin: system/options/cgi/query-string
]
submitted: decode-cgi submitted-bin

That replaces this Apache CGI code:

#!./rebol276 -cs
REBOL []
print "content-type: text/html^/"
print [<HTML><HEAD><TITLE>"Sitebuilder"</TITLE></HEAD><BODY>]
read-cgi: func [/local data buffer][
    switch system/options/cgi/request-method [
        "POST" [
            data: make string! 1020
            buffer: make string! 16380

            while [positive? read-io system/ports/input buffer 16380][
                append data buffer
                clear buffer
            ]
        ]
        "GET" [data: system/options/cgi/query-string]
    ]
    data
]
submitted: decode-cgi submitted-bin: read-cgi

HTH :)
Dockimbel:
17-Apr-2011
I think I have found an issue with /Core 2.7.8 on OS X, the READ-CGI 
mezz is missing! That's making Cheyenne (rev 127) crash on any CGI 
script request.
Dockimbel:
17-Apr-2011
It crashes only if you call READ-CGI.
onetom:
17-Apr-2011
ah, ok, i see it in source read-cgi
Dockimbel:
17-Apr-2011
I have included the READ-CGI mezz in CGI.r to make CGI work on /Core 
2.7.8 on OS X. Testing, will push it in a couple of minutes.
Dockimbel:
17-Apr-2011
Changes commited to revision 128:

FEAT: added support for 'access-os native. Now Cheyenne can work 
with /Core on MacOS X.

FIX: READ-CGI mezzanine is missing in /Core 2.7.8 on MacOS X, Cheyenne 
is now supplying it in such case.
onetom:
17-Apr-2011
how can i test the read-cgi issue?