头使用HttpSelfHostServer消失时, [英] Headers disappearing when using HttpSelfHostServer

查看:784
本文介绍了头使用HttpSelfHostServer消失时,的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在迁移从WCF一个相当广泛的REST服务ASP.NET的WebAPI的过程。我们使用授权头从客户端发送令牌服务器,我实现了与code与401尽快回应,因为它认为没有有效的Authorization头一个DelegateHandler。在code的简化可以在这里看到:

I'm in the process of migrating a rather extensive REST service from WCF to ASP.NET WebAPI. We are using the Authorization header to send tokens from client to the server, and I implemented a DelegateHandler with code that responds with a 401 as soon as it sees there is no valid Authorization header. A simplification of the code can be seen here:

public class AuthenticationHandler : DelegatingHandler
{
    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        if (request == null) throw new ArgumentNullException("request");
        return !IsClientAuthorized(request)
            ? Task<HttpResponseMessage>.Factory.StartNew(() => new HttpResponseMessage(HttpStatusCode.Unauthorized))
            : base.SendAsync(request, cancellationToken);
    }

    private bool IsClientAuthorized(HttpRequestMessage request)
    {
        return request != null && !string.IsNullOrEmpty(request.Headers.Authorization.ToString());
    }
}

在IIS托管时,它工作正常,但对于集成测试我使用HttpSelfHostServer,这里的Authorization头不上的Htt prequestMessage present,即使我能看到它的提琴手发送跟踪。

It works fine when hosted in IIS, but for integration tests I am using HttpSelfHostServer, and here the Authorization header is not present on the HttpRequestMessage, even though I can see it was sent on the Fiddler trace.

我试图让使用自托管来验证问题是一致的一个非常简单的WebAPI的应用程序,但不幸的是它工作正常那里。因此,它必须以某种方式与我的code,但我完全空白是什么原因造成的。

I tried to make a really simple WebAPI application using self hosting to verify that the problem is consistent, but unfortunately it works as expected there. So it must be related to my code somehow, but I am completely blank to what is causing it.

有没有其他人看到这种行为,或有没有人对如何追查中的WebAPI栈它出错的建议?

Has anyone else seen this behavior, or does anyone have suggestions for how to trace where in the WebAPI stack it goes wrong?

推荐答案

原来,这个问题要由授权头格式造成的发送。我们希望授权头看起来像这样:

The problem turned out to be caused by the format of the Authorization header being sent. We would expect the Authorization header to look something like this:

Authorization: 42w4hGtmB7blLOXjcsx8AIbBEhxNpQpj3VNnf89vvjAkJEoX9S+JtmkYZcth+B9y/8Cc3tm1XDOFxGTqN1Hi2Q==

这工作得很好WCF之下,但它是根据HTTP标准,这需要一个计划和值未格式化。例如:

This worked fine under WCF, but it is not formatted according to the HTTP standard, which expects a scheme and a value. For example:

Authorization: XAPI 42w4hGtmB7blLOXjcsx8AIbBEhxNpQpj3VNnf89vvjAkJEoX9S+JtmkYZcth+B9y/8Cc3tm1XDOFxGTqN1Hi2Q==

我的猜测是,仅在头的价值,网络API会认为这是该计划,只有某些字符被允许在这里。当我加入XAPI的方案,使用的值相同一切工作的罚款,并授权头可用到我的code上的Htt prequestMessage.Headers.Authorization。

My guess is that with only the value in the header, Web API would regard this as the scheme, and only certain characters are allowed in here. When I added XAPI as the scheme and used the same value everything worked fine, and the Authorization header was available to my code on HttpRequestMessage.Headers.Authorization.

不过,我认为这是Web API的一个bug,该请求被允许继续进行和头不理,如果它有一个无效的格式。我希望如果头被按规定无效它与一个400错误的请求作出回应。

However I think it is a bug in Web API, that the request is allowed to proceed and the header is just ignored, if it had an invalid format. I would expect it to respond with a 400 Bad Request if a header was invalid according to specification.

这篇关于头使用HttpSelfHostServer消失时,的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆