WEBFS(4) WEBFS(4)
NAME
webfs - world wide web file system
SYNOPSIS
webfs [ -c cookiefile ] [ -m mtpt ] [ -s service ]
DESCRIPTION
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 /srv/service.
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:
chatty9p
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 debug-
ging, at the whim of the library. The default for this
and the following debug flags is 0.
fsdebug
This variable is the level of debugging output about
the file system module.
cookiedebug
This variable is the level of debugging output about
the cookie module.
urldebug
This variable is the level of debugging output about
URL parsing.
acceptcookies
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.
sendcookies
This flag controls whether to present stored cookies to
Page 1 Plan 9 (printed 12/22/24)
WEBFS(4) WEBFS(4)
remote web servers. The default is on.
redirectlimit
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.
useragent
Webfs sends the value of this attribute in its
User-Agent: header in its HTTP requests. The default
is ``webfs/2.0 (plan 9).''
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.
Each connection has its own private set of acceptcookies,
sendcookies, redirectlimit, and useragent variables, ini-
tialized 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 associ-
ated 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.
scheme:schemedata
http://host/path[?query][#fragment]
ftp://[user[:password]@]host/path[;type=ftptype]
file:path
If there is associated data to be posted with the request,
it can be written to postbody. Finally, opening body initi-
ates 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
Page 2 Plan 9 (printed 12/22/24)
WEBFS(4) WEBFS(4)
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 format.
These files contain one line per cookie; each cookie com-
prises some number of attr=value pairs. Cookie attributes
are:
name=name
The name of the cookie on the remote server.
value=value
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, confus-
ingly, name and value are the values associated with
the name and value attributes.
domain=domain
If domain is an IP address, the cookie can only be used
for URLs with host equal to that IP address. Other-
wise, 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
www.not-bell-labs.com).
path=path
The cookie can only be used for URLs with a path begin-
ning with path.
version=version
The version of the HTTP cookie specification, specified
by the server.
comment=comment
A comment, specified by the server.
expire=expire
The cookie expires at time expire, which is a decimal
number of seconds since the epoch.
secure=1
The cookie may only be used over secure (https) connec-
tions. Secure connections are currently unimplemented.
explicitdomain=1
The domain associated with this cookie was set by the
server (rather than inferred from a URL).
Page 3 Plan 9 (printed 12/22/24)
WEBFS(4) WEBFS(4)
explicitpath=1
The path associated with this cookie was set by the
server (rather than inferred from a URL).
netscapestyle=1
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.
EXAMPLE
/sys/src/cmd/webfs/webget.c is a simple client.
SOURCE
/sys/src/cmd/webfs
SEE ALSO
hget(1), webcookies(4)
BUGS
It's not clear what the relationship between hget,
webcookies and webfs should be.
Page 4 Plan 9 (printed 12/22/24)