4 HTTP: Hypertext Transfer Protocol
The Web Server implements many HTTP libraries that are provided by this module.
4.1 Requests
Represents a header of field to value.
Returns the header with a field equal to id from heads or #f.
Returns the header with a field case-insensitively equal to id from heads or #f.
You almost
always want to use this, rather than
headers-assq because Web browsers may send headers with arbitrary casing.
Represents a binding of id.
Represents a form binding of id to value.
Represents the uploading of the file filename with the id id
and the content content, where headers are the additional headers from
the MIME envelope the file was in. (For example, the #"Content-Type" header may
be included by some browsers.)
Returns the binding with an id equal to id from binds or #f.
Like
bindings-assq, but returns a list of all bindings matching
id.
An HTTP method request to uri from client-ip
to the server at host-ip:host-port with headers/raw
headers, bindings/raw GET and POST queries and post-data/raw
POST data.
You are unlikely to need to construct a request struct.
Here is an example typical of what you will find in many applications:
4.2 Bindings
These functions, while convenient, could introduce subtle errors into your
application. Examples: that they are case-insensitive could introduce
an error; if the data submitted is not in UTF-8 format, then the conversion
to a string will fail; if an attacker submits a form field as if it were
a file, when it is not, then the
request-bindings will hold a
bytes? object and your program will error; and, for file uploads
you lose the filename.
Therefore, we recommend against their use, but
they are provided for compatibility with old code.Returns the single binding associated with
id in the a-list
binds
if there is exactly one binding. Otherwise raises
exn:fail.
Returns a list of all the bindings of id in the a-list binds.
Returns #t if binds contains a binding for id.
Otherwise, #f.
Here is an example typical of what you will find in many applications:
4.3 Responses
An HTTP response where output produces the body by writing to
the output port. code is the response code, message
the message, seconds the generation time, mime the
MIME type of the file, and headers are the headers.
If
headers does not include
Date,
Last-Modified, or
Server headers, then the server
will automatically add them, where
Date is based on
current-seconds,
Last-Modified is based on
seconds, and
Server is
Racket.
If headers does not include Content-Type and
mime is not #f, then mime is added as a
Content-Type header.
The server will always replace your Connection header if it
needs to ensure the connection will be closed. (Typically with an
HTTP/1.0 client.)
Changed in version 1.2 of package web-server-lib: Contract on output weaked to allow any
as the result (instead of demanding void?).
A constructor for responses where body is the response body.
Equivalent to
(response code message seconds mime-type headers output)
Changed in version 1.2 of package web-server-lib: Contract on output weaked to allow any
as the result (instead of demanding void?).
Equivalent to #"text/html; charset=utf-8".
Warning: If you include a Content-Length header in a response that is inaccurate, there will be an error in
transmission that the server will not catch.
4.4 Placing Cookies
This module provides functions to create cookies and responses that set them.
Constructs a cookie with the appropriate fields.
Constructs a header that sets the cookie.
4.5 Authenticated Cookies
Cookies are useful for storing information of user’s browsers and
particularly useful for storing identifying information for
authentication, sessions, etc. However, there are inherent
difficulties when using cookies as authenticators, because cookie data
is fully controlled by the user, and thus cannot be trusted.
This module provides functions for creating and verifying
authenticated cookies that are intrinsically timestamped. It is based
on the algorithm proposed by the
MIT Cookie Eaters: if you store
the data
data at thime
authored-seconds, then the
user will receive
digest&authored-seconds&data, where
digest is an HMAC-SHA1 digest of
authored-seconds
and
data, using an arbitrary secret key. When you receive a
cookie, it will reverify this digest and check that the cookie’s
authored-seconds is not after a timeout period, and only
then return the cookie data to the program.
The interface represents the secret key as a byte string. The best way
to generate this is by using random bytes from something like OpenSSL
or
/dev/random.
This
FAQ lists a few options. A convenient purely Racket-based option is
available (
make-secret-salt/file), but it will not have as
good entropy, if you care about that sort of thing.
Generates an authenticated cookie named name containing value, signed with secret-salt.
Extracts the first authenticated cookie named name that was previously signed with secret-salt before timeout from request. If no valid cookie is available, returns #f.
Generates a cookie named name that is not validly authenticated.
This will cause non-malicious browsers to overwrite a previously set
cookie. If you use authenticated cookies for login information, you
could send this to cause a "logout". However, malicious browsers do
not need to respect such an overwrite. Therefore, this is not an
effective way to implement timeouts or protect users on
public (i.e. possibly compromised) computers. The only way to securely
logout on the compromised computer is to have server-side state
keeping track of which cookies (sessions, etc.) are invalid. Depending
on your application, it may be better to track live sessions or dead
sessions, or never set cookies to begin with and just use
continuations, which you can revoke with
send/finish.
Extracts the bytes from secret-salt-path. If
secret-salt-path does not exist, then it is created and
initialized with 128 random bytes.
4.6 Extracting Cookies
While server cookies are represented with
cookie?s, cookies
that come from the client are represented with a
client-cookie structure.
Extracts the cookies from req’s headers.
4.7 Redirect
Generates an HTTP response that redirects the browser to uri,
while including the headers in the response.
Determines if v is one of the following values.
4.8 Basic Authentication
An implementation of HTTP Basic Authentication.
Returns a header that instructs the Web browser to request a username and password from the client using
Basic authentication with realm as the realm.
Returns a pair of the username and password from the authentication
header in req if they are present, or #f.
4.9 Digest Authentication
An implementation of HTTP Digest Authentication.
Returns a header that instructs the Web browser to request a username and password from the client
using Digest authentication with realm as the realm, private-key as the server’s
contribution to the nonce, and opaque as the opaque data passed through the client.
Returns the Digest credentials from req (if they appear) as an association list.
Used to look up the password for a user is a realm.
Used to compute the user’s secret hash.
Uses lookup-password to find the password, then computes the
secret hash of it.
Constructs a function that checks whether particular Digest credentials
(the second argument of the returned function) are correct given the
HTTP method provided as the first argument and the secret hash computed
by lookup-HA1.
This is will result in an exception if the Digest credentials are
missing portions.
4.10 X-expression Support
Equivalent to
This is a viable function to pass to set-any->response!.