Mapping between file system API and HTTP requests and responses

File System API callHTTP 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 countNone
Perform a regular read(2) operation on the cached-file-handle.

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

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

stat filename-URL struct-stat-bufferHEAD 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-handleNone
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-handleNone
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.

 


Last updated June 25, 1999

This site's top page is http://pobox.com/~oleg/ftp/