Mapping between file system API and HTTP requests and responses

File System API call	HTTP request issued
`open filename-URL oflags mode`	`GET filename-URL` `Pragma: httpfs="preopen-xxxx"` `If-modified-since: yyyyy`
where `xxxx` encodes the file status flags and file access modes as given by oflags: `O_RDONLY`, `O_RDWR`, `O_WRONLY`, `O_CREAT`, `O_EXCL` and `O_TRUNC`. The HTTPFS server delivers the file if needed, and verifies that the resource can indeed be retrieved, modified, created or truncated. A `VNodeFile` is created to describe the opened resource and point to a local file that holds the (cached) copy of the resource. This local file is then opened, and the corresponding handle is returned to the caller. If the file is being opened for modification, a dirty bit of the `VNodeFile` is set. A `VNodeFile` corresponding to the `filename-URL` might have already existed in a `VNode` cache. In that case, the GET request will include an `If-modified-since: yyyyy` header, where `yyyyy` is the value of a `VNode::last_checked` field in HTTP date format.

`close cached-file-handle`	`PUT filename-URL`
Locate a `VNode` whose opened cache file has a handle equal to the `cached-file-handle`. If the `filename-URL` has been opened for writing (that is, `VNodeFile::dirty` is set), upload the contents of the cache file to the HTTPFS server. The `VNode` and its cached content are not immediately disposed of, but rather stay around until "garbage-collected".

`read cached-file-handle buffer count`	None
Perform a regular `read(2)` operation on the `cached-file-handle`.

`write cached-file-handle buffer count`	None
Perform a regular `write(2)` operation on the `cached-file-handle`.

`lseek cached-file-handle offset whence`	None
Perform a regular `lseek(2)` operation on the `cached-file-handle`.

`stat filename-URL struct-stat-buffer`	`HEAD filename-URL` `Pragma: httpfs="stat"`
First we check to see if there is a valid `VNode` for the given `filename-URL` (possibly with a '/' appended, in case it turns out to be a directory). If such a `VNode` is found, its cached status information is immediately returned and a HTTPFS server is not bothered. Otherwise, we issue the HEAD request and fill in the `struct-stat-buffer` from the `status-info` in a `Etag:` response header.

`lstat filename-URL struct-stat-buffer`	`HEAD filename-URL` `Pragma: httpfs="lstat"`
Similar to the `stat` API call above.

`readlink filename-URL filename-buffer`	`HEAD file-name` `Pragma: httpfs="readlink"`
Fill in the `filename-buffer` with the response from the server.

`opendir dirname-URL`	`GET dirname-URL` `If-modified-since: yyyyy`
A new `VNodeDir` is created for the `dirname-URL`, unless the corresponding valid `VNodeDir` happens to exist in the `VNode` cache. In the latter case, the GET request will carry the `If-modified-since: yyyyy` header with `yyyyy` being the value of a `VNode::last_checked` field. The server returns the listing of the directory: for each directory entry (including `.` and `..`) the server writes a line `name/status-info` This listing is written as it is into a cache file of the `VNodeDir`. The `VHandle` of this `VNodeDir` is returned as the result of the `opendir()` call.

`readdir VNodeDir-handle`	None
The `dir-handle` is supposed to be a `VHandle` of a `VNodeDir`. This `VNode` is located, its cache file is parsed and sent to a MCFS client (as a sequence of `name`, `stat-for-the-name` pairs).

`closedir VNodeDir-handle`	None
The `VNodeDir-handle` is supposed to be a `VHandle` of a `VNodeDir`, which is thus closed.

`rmdir dirname-URL`	`DELETE dirname-URL`
`mkdir dirname-URL mode`	`PUT dirname-URL`
`unlink filename-URL`	`DELETE filename-URL`

status-info, the status information for a remote resource, is a string of 11 numbers separated by a single space:

     dev ino mode nlink uid gid size atime mtime ctime blocks

All numbers are in decimal notation, except mode which is octal. The meaning of the numbers is the same as that of the corresponding fields in a stat structure. See also a stat entry in Perl documentation. The status-info is a "hard validator" of a resource -- resource's unique identification. Indeed, should the file get altered, at least its modification timestamp will change. The status-info is delivered in a ETag: response header, a field designated by the HTTP standard to carry (unique) resource identifiers.

Mapping between file system API and HTTP requests and responses

Last updated June 25, 1999