One technique to overcome this problem is to split off the free file space
response into a separate HTTP method. An additional method, METRICS, could
return the server free file space datum as well as any others that would be
helpful to a browser. Alternatively, METRICS could take an argument:
METRICS metricname
where "metricname" is the name of a metric, with "ALL" reserved for all
supported server metrics values. Even though the problem of how much free
space is available on a server cannot be solved in most server environments
(all multi-tasking environments that support file size increases in the
background), an HTTP server can just make an educated guess as to how much
space a browser can safely consume. From my experience, it is likely that
this guess will be good enough to reduce network traffic substantially; it
is less likely (IMHE (in my humble experience)) that a browser user will
want to upload files that come very close to filling up their allocated
space than the case of those files taking up either significantly less or
more than the browser user's free space. If the volatility of free space on
a server is not close to that of the majority of file uploads, an educated
guess should work pretty well (cf. Craig Milo Rogers in
<11428.782066705@drax.isi.edu>). If it is, then you will get into a
thrashing state, where file uploads will appear to fail randomly as the
educated guess is just not good enough.
METRICS could either be run "in the background" as scheduled by the browser
or when HTML specifying a file upload widget was seen by the browser, the
browser could force a METRICS method to run before permitting the browser
user to perform their POST.
======================================================================
Mark Fisher Thomson Consumer Electronics
fisherm@indy.tce.com Indianapolis, IN
"Just as you should not underestimate the bandwidth of a station wagon
traveling 65 mph filled with 8mm tapes, you should not overestimate
the bandwidth of FTP by mail."