Webfs presents a file system interface to the parsing and retrieving
of URLs. Webfs mounts itself at mtpt (default /mnt/web), and,
if service is specified, will post a service file descriptor in
Webfs presents a three–level file system suggestive of the network
protocol hierarchies ip(3) and ether(3).
The top level contains three files: ctl, cookies, and clone.
The ctl file is used to maintain parameters global to the instance
of webfs. Reading the ctl file yields the current values of the
parameters. Writing strings of the form ``attr value'' sets a
particular attribute. Attributes are:
The chatty9p flag used by the 9P library, discussed in 9p(2).
0 is no debugging, 1 prints 9P message traces on standard error,
and values above 1 present more debugging, at the whim of the
library. The default for this and the following debug flags is
This variable is the level of debugging output about the file
This variable is the level of debugging output about the cookie
This variable is the level of debugging output about URL parsing.
This flag controls whether to accept cookies presented by remote
web servers. (Cookies are described below, in the discussion of
the cookies file.) The values on and off are synonymous with 1
and 0. The default is on.
This flag controls whether to present stored cookies to remote
web servers. The default is on.
Web servers can respond to a request with a message redirecting
to another page. Webfs makes no effort to determine whether it
is in an infinite redirect loop. Instead, it gives up after this
many redirects. The default is 10.
The top–level directory also contains numbered directories corresponding
to connections, which may be used to fetch a single URL. To allocate
a connection, open the clone file and read a number n from it.
After opening, the clone file is equivalent to the file n/ctl.
A connection is assumed closed once all files
in its directory have been closed, and is then will be reallocated.
Webfs sends the value of this attribute in its User–Agent: header
in its HTTP requests. The default is ``webfs/2.0 (plan 9).''
Each connection has its own private set of acceptcookies, sendcookies,
redirectlimit, and useragent variables, initialized to the defaults
set in the root's ctl file. The per–connection ctl file allows
editing the variables for this particular connection.
Each connection also has a URL string variable url associated
with it. This URL may be an absolute URL such as http://www.lucent.com/index.html
or a relative URL such as ../index.html. The baseurl string variable
sets the URL against which relative URLs are interpreted. Once
the URL has been set, its pieces can be
retrieved via individual files in the parsed directory. Webfs
parses the following URL syntaxes; names in italics are the names
of files in the parsed directory.
If there is associated data to be posted with the request, it
can be written to postbody. Finally, opening body initiates the
request. The resulting data may be read from body as it arrives.
After the request has been executed, the MIME content type may
be read from the contenttype file.
The top–level cookies file contains the internal set of HTTP cookies,
which are used by HTTP servers to associate requests with persistent
state such as user profiles. It may be edited as an ordinary text
file. Multiple instances of webfs and webcookies(4) share cookies
by keeping their internal set consistent with the
cookiefile (default $home/lib/webcookies), which has the same
These files contain one line per cookie; each cookie comprises
some number of attr=value pairs. Cookie attributes are:
The name of the cookie on the remote server.
The value associated with that name on the remote server. The
actual data included when a cookie is sent back to the server
is ``name=value'' (where, confusingly, name and value are the
values associated with the name and value attributes.
If domain is an IP address, the cookie can only be used for URLs
with host equal to that IP address. Otherwise, domain must be
a pattern beginning with a dot, and the cookie can only be used
for URLs with a host having domain as a suffix. For example, a
cookie with domain=.bell–labs.com may be used
on hosts www.bell–labs.com and www.research.bell–labs.com (but not
The cookie can only be used for URLs with a path beginning with
The version of the HTTP cookie specification, specified by the
A comment, specified by the server.
The cookie expires at time expire, which is a decimal number of
seconds since the epoch.
The cookie may only be used over secure (https) connections. Secure
connections are currently unimplemented.
The domain associated with this cookie was set by the server (rather
than inferred from a URL).
The path associated with this cookie was set by the server (rather
than inferred from a URL).
The server presented the cookie in ``Netscape style,'' which does
not conform to the cookie standard, RFC2109. It is assumed that
when presenting the cookie to the server, it must be sent back
in Netscape style as well.