Tim's work items

0.  Undocumented Bonus Work Item:  HTTP:HEAD
 
I spoke with several folks in a position to know, and wanted to share their
thoughts with you.   HTTP:HEAD can't be scripted, it has to be sent directly
(read: binary).  What you get back will depend on what the server is capable
of telling you.  It will not in any known scenario return the number of
bytes that a link will return, because it doesn't recurse.  Byte count will
reflect the HTML and text only, no images, count of images, etc. The only
way around this would be to execute some code at the server that would load
the requested page to a local (to the server) page, and count the bytes as
that happened, returning that to the requestor.
 
1.  Possible error codes
 
I would classify the possible errors into two groups:  A physical channel
error, such as a dropped internet connection, and a content error, such as
asking for a non-existent page.  I use the term content in that the channel
is good, but the content of the request generated an error.
 
Physical errors:
Server not found (in the case of a known good - and online - server)
Invalid DNS entry
No internet connection detected
...Plus any number of error messages that may be generated by any proxies,
firewalls, etc.
 
Content errors:
HTTP Error codes found in IE DLL's:
 
400 Bad Request
403 Forbidden
404 Not Found
406 Not Acceptable
410 Gone
500 Internal Server Error
501 Not Implemented
 
A note on errors:  I haven't read the RFC in it's entirety, but it is my
understanding that any/all HTTP errors have the same recovery mode: try it
again, which is to say, there isn't a recovery mode.
 
2.  From the archives:
 
9.4 When transferring content (e.g., a document, image, audio, video, etc.)
indicate what percentage of the content has been transferred and whether the
transfer has stalled.
 
Proposed:


9.4 When transferring content (e.g., a document, image, audio, video, etc.)
indicate what percentage of the content has been transferred and whether the
transfer has been interrupted.
 
Reasoning:  "Stalled" implies that a process can be "UnStalled", which in
the case of an HTTP transfer, is not possible once the timeout has expired.
To me, "interrupted" doesn't have as strong an implication.  I originally
thought "failed" would be good, but we then have the case that an FTP
transfer *can* be un-stalled.  Sigh.
 
This also doesn't address the exception for streaming content, which has no
'size'.
 
Tim Lacy
Accessibility Program Manager
Accessibility & Disabilities Group
http://enable <http://enable/>