http progress notification

We've made some more great progress with testing on this, which has lead 
to a fairly major change in the structure of information passed back by 
servers.

We have a Google Chrome client available for testing, and an 
experimental WinGate proxy as well using Kaspersky AV for WinGate to 
provide the updates during spooling for scanning.

Test results are very promising, and in my view provide clear benefits 
and incentives.

In a nutshell, the changes to the Internet Draft are as follows:

1. Client advertisement.

This is now done by way of adding a token to the Connection or 
Proxy-Connection request header - e.g.

Connection: Keep-Alive, Progress

2. Server / intermediary responses.

The current experimental implementation returns status codes of 102.  
The data returned is in a list of name value pairs.
Currently we have defined the following:

"state"    represents the current state, defined values are: GENERATING, 
RECEIVING, SENDING or PROCESSING (no quotes, case sensitive)
"agent"   a quoted string representing the subject of the current state
"bytes"    a number of bytes (either sent or received) which makes sense 
mostly for RECEIVING and SENDING.  Omit if not relevant for the state
"size"      the size of the entity in bytes (if known). Omit if not known.
"percent" percent complete of any stage

as an example, downloading and scanning a hypothetical 10k file (over a 
very slow link) produces something like:

HTTP/1.1 102 OK
Progress: state=RECEIVING,agent="WinGate",bytes=1024,size=10240

HTTP/1.1 102 OK
Progress: bytes=2048

HTTP/1.1 102 OK
Progress: bytes=4096

HTTP/1.1 102 OK
Progress: bytes=8192

HTTP/1.1 102 OK
Progress: bytes=10240

HTTP/1.1 102 OK
Progress: state=PROCESSING,agent="Kaspersky AV",percent=0

HTTP/1.1 102 OK
Progress: percent=10

HTTP/1.1 102 OK
Progress: percent=100

HTTP/1.1 200 OK
Content-Length: 10240
Content-Type: etc.....

We only send new values for a parameter if it changes, e.g. if the state 
changes, or agent changes, or bytes changes.  I've omitted Date headers 
in the example above.

All fields except state are optional.  What this means is that at least 
the first interim response must specify a state, but all other fields 
are optional.  It is valid simply to indicate state and changes in state.

We considered sending all progress data each time, but this redundant 
information just causes extra bandwidth consumption which I considered 
hard to justify purely to avoid storage of state in the client.  Our 
current implementation sends on any state change or data size downloaded 
change (max 2/sec).  It sends bytes for downloads, and percents for 
scanning.

The main reasons we adopted this new approach (c.f. the I-D) were:

a) it's extensible.
* We can add more data as required (e.g. entity content-type perhaps to 
enable a client to display a "save as" dialog)
* we can add more states as required, although these will require some 
form of registry.  I'd propose we give some thought to states we wish to 
be able to distinguish and get a set from the start that won't need 
extending for a long time if ever.
b) dealing with unknown lengths is simpler than the original proposal - 
just omit the size field.
c) it's closer in structure to existing headers so parsing should be easier.

I'd propose that anyone wanting to contribute to this let me know, I can 
also make available software for testing.  Then after a week or so I'll 
update the I-D.

Regards

Adrien

Received on Tuesday, 25 May 2010 04:16:33 UTC