AltME groups: search
Help · search scripts · search articles · search mailing listresults summary
world | hits |
r4wp | 8 |
r3wp | 25 |
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? |