We're nowhere near robust enough in the face of network errors.

Most of the problems with HTTP error handling (like the recent 
problems loading StarBrowser when it had a bad URL) can be traced to 
one place:

HTTPSocket, httpGetDocument: url args: args accept: mimeType request: 
requestString

There are several problems with it:

* It returns either a MIMEDocument or a String (on error). The String 
then later has to be parsed if you're interested in the errors.

* It throws away HTTP header and other information, especially error 
codes.

* It prompts the (possibly nonexistent) user for retries when the 
NameResolver is having problems

* It has a fixed retry count of 3

Then, to make a bad situation worse, calling normalizeContents: on 
this return value (as is done in 
HTTPUrl>>retrieveContentsArgs:accept:) turns even errors into 
MIMEDocuments, making them indistinguishable from real contents.

I'd be in favor of just throwing a retryable exception on HTTP errors 
(and tracking down callers of 'isKindOf: String' and 'isString' that 
try to determine error conditions). This would give clients the 
ability to have their own retry/error handling, and wouldn't throw 
away information (I'd package the entire HTTP response into the 
exception).

And I'd push the NameResolver errors into an exception as well, with 
perhaps its default handling being to prompt a user.

Has anyone fixed this already? It seems like it'd be a great addition 
to the network rewrite using Michael's (and Craig's?) code.

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE