Has anybody already created HttpResponse and HttpRequest objects?

Ned Konz wrote:

>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.
>
>  
>