|Request object is accessible for the scripts
executed by the ScripgGen content generator - RAW and ASP compatible
pages. It provides access to the
request passed by the browser - URL, form post, various environment information
QueryString - Contains the
parameters passed to the script through the URL or forms submitted using GET method
Form - Contains the content of the form
post - i.e. forms submitted using the POST method.
ServerVariables - Contains set
of the values indicating various environment information such as script name, path, ALP
version, site path and so on
- Reads the input stream. Used mostly for file uploads and custom
transfers (not invoked by the browser).
- The size of the data received. How many bytes can be read through
the BinaryRead method.
Important comments about all the
Request can be used directly - its default property allows indexing. For
<%= Request("param") %>
In such case Request object searches its collections and returns
found collection of strings corresponding to the given name in the brackets. Search occurs
in this order:
1. QueryString collection
2. Form collection
3. ServerVariables collection
I.e. If you use Request("myfield") the
Request will look in the QueryString collection, if there is an
element with this name in it - it will return it, if not it will
continue to search the next collections. If the parameter is not found
a string collection with a single empty string is returned. Assuming
the names of the server variables are usually very specific this feature can
help to build scripts that work with query string and form posts no
matter how the parameter is passed.
One usage idea is results paginating - in that case
links are often used to direct the user to the corresponding page.
Assume the list represents results of a DB query. In that case
the first invocation of the script is typically through the posted form and then the
script needs to generate hyper links that the user can click in order to view next/other
part of the query results. If the page uses Request("field_name")
you can create links that carry the values submitted through the form
used to initiate the search.
Features from the classic ASP without equivalent in
Cookies - ALP cannot afford to support cookies
without causing side problems. The cookies standard binds them to an
HTTP/HTTPS URL therefore any cookies support will require fake URL or
other tricks. Furthermore the ALP applications can run from any
location and the location may change - this means that a cookie may be
lost when the location changes (for a good example consider an
application designed to run directly from a flash memory). These and
other similar problems caused us to abandon the cookies support for
now in order to avoid tempting the developers implement code that is
potentially dangerous. If we resort to cookie support implementation
it will be very limited and will require additional
ClientCertificate - Inappropriate for ALP.