Makes sense to me,[ ... ]
I would definatly agree on your point that 'Client' logic should be in HttpClient and not in HttpMethodBase. (I would say redirect, auth and even auto-retry would count as 'Client' logic).
I would also agree. I would like and expect my use of the library to be one-to-one with respect to HTTP methods eg I ask it to do one thing and it does it. If anything makes the fetch not `complete' then it informs me and I decide whether to do a retry/follow a redirect/handle authentication.
Also:
- In my context the limits on redirects are not local to a call ie the number of redirects that are allowed on any one call may be affected by the general number of fetches that have been done so far.
- I require full control of when a fetch is done. This is to allow limiting of number and type of hits to a web server. If auto-retry is enabled then I have no way of throttling or scheduling hits.
As I think Laura has mentioned, it would be nice if HttpClient could be decomposed into reusable components for implementing a user agent, but it is essential that I be able to peel away any user agent layer that exists. From the sound of it, the current HttpMethodBase does too much on its own for me to use it.
-- Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
