有没有办法更改 400/500 状态代码上的 HttpWebRequest 行为?

发布于 2024-11-05 17:53:29 字数 747 浏览 3 评论 0原文

我正在致力于在 .NET 中的 HttpWebRequest/HttpWebResponse 类型之上构建流畅的 REST 客户端界面。到目前为止,一切都很好...但是我正在尝试开发一个可插入的安全框架,它可以自动处理安全令牌协商、令牌刷新等。

由于 HttpWebRequest/Response 的性质,我遇到了问题 在遇到 400 系列或 500 系列 HTTP 状态代码时起作用。它们不是简单地设置 .StatusCode.StatusDescription 属性并允许您以任何您希望的方式进行处理,而是抛出 WebException。一般来说,这可能不是问题......但是我们的身份验证方式(OAuth 2.0 的派生),我需要处理某些 400 系列错误而不发生异常。

是否有某种方法可以重新配置 HttpWebRequest/Response 以不抛出 WebException,并允许使用者确定自己的错误处理?我知道有一些迂回的方式来处理旧的 Http1.0 服务器的 Expect-100-Continue...我很好奇是否有类似的迂回方式来禁用 WebExceptions。

(哦,就是无法抗拒...向我在 RedGate 的好朋友们大声喊叫,因为他们非法拿走了 Reflector 6 的受许可证限制的免费版本...我也许能解决这个问题就我自己而言,如果我可以窥探代码……但是可惜……遗憾的是,Reflector 现在是一个不可行的选择,因为它已经通过自解消耗了自己;P)

I am working on building a fluent REST client interface on top of the HttpWebRequest/HttpWebResponse types in .NET. So far, so good...however I am trying to develop a pluggable security framework that can automatically handle security token negotiation, token refreshes, etc.

I've run into a problem due to the nature of how HttpWebRequest/Response work when they encounter a 400 series or 500 series HTTP status code. Rather than simply setting the .StatusCode and .StatusDescription properties and allowing you to handle in whatever way you wish, they throw a WebException. Generally speaking, this probably isn't a problem...however the way we are authenticating (derivative of OAuth 2.0), I need to handle certain 400 series errors without an exception occurring.

Is there some way to reconfigure HttpWebRequest/Response to NOT throw WebException, and allow the consumer to determine their own error handling? I know that there are some round-about ways of handling Expect-100-Continue with older Http1.0 servers...I'm curious if there is a similar round-about way to disable WebExceptions.

(Oh, and just can't resist...a BIG OL' SHOUT OUT to my WONDERFUL friends over at RedGate for illegally taking away the license-bound FREE version of Reflector 6...I might be able to figure this one out on my own if I could snoop the code...but alas...Reflector is sadly an nonviable option now that it has consumed itself via autolysis. ;P )

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

逆光飞翔i 2024-11-12 17:53:29

我遇到了类似的问题并使用以下辅助方法解决了它:

public static HttpWebResponse MakeRequest(HttpWebRequest request)
{
    try
    {
        return (HttpWebResponse)request.GetResponse();
    }
    catch (WebException we)
    {
        if (we.Response != null)
        {
            return (HttpWebResponse)we.Response;
        }
        throw;
    }
}

I had a similar problem and solved it with the following helper method:

public static HttpWebResponse MakeRequest(HttpWebRequest request)
{
    try
    {
        return (HttpWebResponse)request.GetResponse();
    }
    catch (WebException we)
    {
        if (we.Response != null)
        {
            return (HttpWebResponse)we.Response;
        }
        throw;
    }
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文