GOLF(2gg)

πŸ“¦ version 601.4.41, in ubuntu questing

πŸ’– GOLF(2gg) πŸ’–

okay bestie, this is the GOLF manual, section 2gg, under Development. pull up a chair, grab a strawberry πŸ“, and let's get into it.


✨ NAME ✨

get-req β€” (request-information)

🎯 PURPOSE 🎯

Obtain data that describes the input request. literally that's the whole job, and she does it flawlessly πŸ’…

πŸ“œ SYNTAX πŸ“œ

get-req \
        errno | error | cookie-count | cookie <cookie index> \
        | arg-count | arg-value <arg index> \
        | header <header> | referring-url | method \
        | content-type | trace-file | process-id | name \
        | external-call | directory | source-file
    to <variable>

πŸ¦‹ DESCRIPTION πŸ¦‹

So the tea is: you can grab all sorts of info about an input request with the get-req statement, and the result goes straight into <variable> (that's the to clause, bestie, don't forget it 🫢). here's everything you can pull (all of these are strings except where it says otherwise, no cap):

  • errno β€” gets you the integer value of the operating system's errno, tied to the last Golf statement that can return a status code. the errno value gets saved internally and restored here, which means even if errno changed for literally any reason since that Golf statement (like, say, via call-extended), you'll still get the correct value. check error-code for an example πŸ‘€ heads up though: the errno value is undefined if there's no error, and it can be 0 if the error was reported by Golf itself and not by the operating system. πŸ’€
  • error β€” returns the error message that correlates to the errno value.
  • cookie-count β€” returns the number of cookies. and by "number of cookies" we mean: any cookies received from the client, plus any cookies added (with set-cookie) in the application, minus any cookies deleted (with delete-cookie). math is mathing, slay.
  • cookie β€” returns the cookie value specified by <cookie index>, which is a sequential number starting with 1 up to the number of cookies. for instance:
get-req cookie-count to cookie_c
start-loop repeat cookie_c use i
    get-req cookie i to cookie_val
    print-format "cookie %s\n", cookie_val web-encode
    @<br/>
end-loop

in this example, we get the number of cookies, and then print out each cookie value. iconic behaviour, honestly. ✨

  • arg-count β€” the number of input arguments to your application (passed from a program caller, see the -a option in mgrg and --arg in gg).
  • arg-value β€” the string value of a single element from the array of input arguments, specified by <arg_index>. this array is indexed from 1 to the value you get from arg-count. here's an example using arg-count and arg-value together:
get-req arg-count to ac
print-format "Total args [%ld]", ac
start-loop repeat ac use i
    get-req arg-value i to av
    print-format "%s\n", av
end-loop

this code displays the number of input arguments (as passed to the main() function of your program, excluding the first argument which is the name of the program), and then all the arguments. if there are no arguments, then variable 'ac' would be 0. simple as πŸŽ€

  • header β€” the value of the HTTP request header <header> that's set by the client. for example, if the HTTP request contains header "My-Header:30", then hval would be "30":
get-req header "My-Header" to hval
ngl, not all HTTP request headers are set by the caller. for example, SERVER_NAME or QUERY_STRING are set by the web server, and to get such headers, use get-sys. 🧚
  • method β€” the request method. it's a number with values of GG_GET, GG_POST, GG_PUT, GG_PATCH or GG_DELETE for GET, POST, PUT, PATCH or DELETE requests, respectively. if it's not any of those commonly used ones, then the value is GG_OTHER, and you can use get-sys with the environment clause to obtain the REQUEST_METHOD variable. periodt. πŸ”₯
  • content-type β€” the request content type. it's a string and generally denotes the content type of a request-body, if one is included in the request. common examples are "application/x-www-form-urlencoded", "multipart/form-data" or "application/json".
  • referring-url β€” the referring URL (i.e. the page from which this request was called, for example by clicking a link). the origin story, if you will πŸ’…
  • directory β€” the current working directory, which by default is the application home directory (see directories) and can be changed with change-dir. > lowkey important: the maximum length of a directory path should not exceed 1024 bytes. don't test her.
  • trace-file β€” the full path of the trace file for this request (if enabled, see trace-run).
  • process-id β€” the "PID" (process ID) number of the currently executing process, as a number.
  • external-call β€” a boolean that is true if the call to the current request handler is from an external caller, or false if called from another handler.
  • source-file β€” the name of the current source file (a string).
  • name β€” the request name as specified in the request URL.

🌈 EXAMPLES 🌈

get the name of the current trace file:

get-req trace-file to trace_file

look at her go. chef's kiss πŸ‘‘


πŸ‘€ SEE ALSO πŸ‘€

  • Request information
  • get-req See all documentation

that's the whole page, bestie! this was GOLF(2gg), version $VERSION, dated $DATE. go forth and get-req responsibly πŸ’–βœ¨πŸŽ€πŸ¦‹πŸŒΈπŸ’…πŸ«Ά

πŸ“¦ where this page comes from