Collections:

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

BinaryRead - Reads the input stream. Used mostly for file uploads and custom transfers (not invoked by the browser).

TotalBytes - The size of the data received. How many bytes can be read through the BinaryRead method.

Important comments about all the Request collections.

Request can be used directly - its default property allows indexing. For example:

<%= Request("param") %>

In such case Request object searches its collections and returns the first 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 ALP:

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 configuration. 

ClientCertificate - Inappropriate for ALP.