WebException.GetResponseStream always throws a

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use 2 way auth with X509 certificate
2. Make an invalid request to a server with valid credentials 
3. Server returns error 400 with a response body (in my case xml describing
the error)
4. In the catch section, attempt to use the following code

 if (ex.Response != null)
            {

                using (StreamReader streamReader = new
StreamReader(ex.Response.GetResponseStream()))
                {
                    Response = streamReader.ReadToEnd();
                }

                if (ex.Response is HttpWebResponse)
                {
                    StatusCode = ((HttpWebResponse)ex.Response).StatusCode;
                }
}

What is the expected output? What do you see instead?

I expect the ability to read from the stream.  I get an exception instead

What version of the product are you using? On what operating system?
Latest trunk

Please provide any additional information below.

This appears to be a bug from the implementation of WebExceptionHelper.cs.
 The helper reads the content stream before the exception is re-thrown to
the caller.  As a result, the stream has been read to the end, and I'm
unable to retrieve the data I need.  I'll be modifying the exception helper
to resolve this issue.

Original issue reported on code.google.com by Todd.nin...@gmail.com on 31 Mar 2010 at 9:35

[GoogleCodeExporter]

I've attached the patch file.  This wraps WebException, but I don't think this 
is
ideal.  Perhaps a better solution would be to expose a public API that allows 
users
to pass a string in and be returned an OAuthException.  This way uses can still 
have
the choice of standard web exceptions, or using the internal API's to wrap
WebExceptions with more specific oAuth help.

Original comment by Todd.nin...@gmail.com on 31 Mar 2010 at 10:40

Attachments:

• exception-wrapping.patch

[GoogleCodeExporter]

Thanks for the patch!

I wonder if perhaps this logic shouldn't be contained in some kind of 
"ExceptionHandlingPolicy" that can be configured just once and then used for 
all 
subsequent requests/responses - as I suspect it might not be a 
"one-size-fits-all" 
situation, like you say.  Especially if they're working against a less then 
ideal 
OAuth server-side implementation (i.e. if it's not implementing OAuth error 
reporting).

What do you think?

Original comment by bitterco...@gmail.com on 6 Apr 2010 at 7:44

[GoogleCodeExporter]

FYI - Patch has been applied, with some minor style etc. tweaks.

Original comment by bitterco...@gmail.com on 6 Apr 2010 at 7:59

[GoogleCodeExporter]

I agree.  Perhaps a delegate callback or an interface for exception handling 
that can
be set when the client is created?  This way each user could customise exception
handling specifically for their needs.  

Original comment by Todd.nin...@gmail.com on 6 Apr 2010 at 10:39

[GoogleCodeExporter]

This issue has now been moved to github:

http://github.com/bittercoder/DevDefined.OAuth/issues#issue/3

Closing this issue as wontfix.

Original comment by bitterco...@gmail.com on 3 Aug 2010 at 8:33

• Changed state: WontFix