- From: Tim Lacy <timla@MICROSOFT.com>
- Date: Fri, 4 Aug 2000 11:56:39 -0700
- To: w3c-wai-ua@w3.org
- Message-ID: <5F68209F7E4BD111A5F500805FFE35B91C72A2DF@RED-MSG-54>
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/>
Received on Friday, 4 August 2000 14:57:49 UTC