WEBFS(4)WEBFS(4)NAMEwebfs - world wide web file system
SYNOPSISwebfs [ -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 pro‐
tocol 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 parame‐
ters. 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 debugging, 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 pars‐
ing.
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 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 correspond‐
ing to connections, which may be used to fetch a single URL. To allo‐
cate 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 con‐
nection 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, 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.
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 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 content‐
type 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 format.
These files contain one line per cookie; each cookie comprises 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, confusingly, name and value are the val‐
ues 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. 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 www.not-bell-
labs.com).
path=path
The cookie can only be used for URLs with a path beginning 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) connections.
Secure connections are currently unimplemented.
explicitdomain=1
The domain associated with this cookie was set by the server
(rather than inferred from a URL).
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 ALSOhget(1), webcookies(4)BUGS
It's not clear what the relationship between hget, webcookies and webfs
should be.
WEBFS(4)
