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 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 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 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, 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 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 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 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. 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 ALSO
hget(1), webcookies(4)

BUGS
It's not clear what the relationship between hget, webcookies and webfs should be.
Copyright © 2018 Alcatel-Lucent. All rights reserved.