IISダンプ後続のスラッシュなしのWCFサービスコール後のリダイレクトでの承認ヘッダー

Question

IIS 7 Webサイトインスタンスで実行されているWCF RESTサービスを組み立てていて、トークンとHMACを挿入するHMAC認証スキームを使用しています。認証ヘッダー典型的なリクエストに応じて例のヘッダリストは、次のようになります。

GET http://api.mydomain.com/Contacts HTTP/1.1 
Authorization: 774F035C-FRTB-4207-DDDD-31BF1534AD96:9h0Whke9Bgi3XSHPo/YSXw== 
Content-Type: application/xml; charset=utf-8 
Host: api.mydomain.com 
Connection: Keep-Alive 

を私は.SVCファイルの代わりに使用してルーティングを設定するサービスを持っているので、私のGlobal.asaxのは、次のようになります。

protected void Application_Start(object sender, EventArgs e) 
    { 
     RouteTable.Routes.Add(new ServiceRoute("Users", new WebServiceHostFactory(), typeof(UsersService))); 
     RouteTable.Routes.Add(new ServiceRoute("Widgets", new WebServiceHostFactory(), typeof(WidgetsService))); 
    } 

このようなルーティングでサービスを宣言すると、IISがWebGet uri の後ろにスラッシュを付けないでのコールを受信すると、に307のリダイレクトが行われ、の末尾にスラッシュが付きます。役に立つと思いますが、ですが、問題はリダイレクトがAuthorizationヘッダーをダンプすることです。

私のサービスクラスはすべて正統派であり、他の点ではすごく優れています。 リダイレクトの際にAuthorizationヘッダーを保持できる方法はありますか？私は、ソリューションがIIS構成のものになると思っていますが、すべての種類のルーティングハッキングを適所に置いて、スラッシュのないバージョンを取得することができると思います。

更新：
が、私はこの動作を検証しますが、本当にすべての修正を与えるものではありませんthis articleを見つけました。

Answer 1

ここでは、IISがここにいる理由を完全にはわかりません。 「承認ヘッダーをダンプする」と言ったら、どういう意味ですか？リダイレクトの一部として再送信しているか、送信していないということですか？

WCF賢明なことに、リダイレクトはおそらく起きている可能性があります。これは、Microsoftでの誰かを叩いて、ほぼになってしまうようなものの1つです。 UriTemplateクラス自体は、末尾のスラッシュを適切に名前を付けてIgnoreTrailingSlash propertyという名前で無視する機能を持っています。残念ながら、WCF WebInvoke/Get属性は実際にはこのプロパティを何らかの方法でマップしていないため、UriTemplateプロパティに入力したものに正確にバインドされたテンプレートを常に作成します。

したがって、最も厄介な最も簡単な回避策は、WCFコントラクトのメソッドに後続のスラッシュを持つ2番目の署名をオーバーロードすることです。たとえば、

[OperationContract] 
[WebGet(UriTemplate="/Users")] 
public List<User> GetUsers() 
{ 
    .... some code here ... 
} 

[OperationContract] 
[WebGet(UriTemplate="/Users/")] 
public List<User> GetUsersSlash() 
{ 
    return this.GetUsers(); 
} 

醜いでしょうか？これが何度も何度も何度も繰り返すパターンであれば特に悪いことです。したがって、セミハルではなくハッキリではない別のオプションは、カスタム動作を介してサービスに適用するカスタムオペレーションセレクタロジックを記述することです。 this StackOverflow answerでこれを行う方法の詳細があります。