Skip to content
This repository was archived by the owner on Nov 20, 2018. It is now read-only.

Adding a feature to get the traceidentifier for a request #210

Merged
merged 1 commit into from
Mar 4, 2015
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 18 additions & 0 deletions src/Microsoft.AspNet.Http.Interfaces/IRequestIdentifierFeature.cs
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
// Copyright (c) Microsoft Open Technologies, Inc. All rights reserved.
// Licensed under the Apache License, Version 2.0. See License.txt in the project root for license information.

using System;

namespace Microsoft.AspNet.Http.Interfaces
{
/// <summary>
/// Feature to identify a request.
/// </summary>
public interface IRequestIdentifierFeature
{
/// <summary>
/// Identifier to trace a request.
/// </summary>
Guid TraceIdentifier { get; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason this is specifically a Guid and not a string? (The OWIN spec doesn't specify a format.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW I'm not suggesting it should be a string, just asking.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Traditionally these have been GUIDs so that they can be flowed via the CorrelationManager.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that makes sense... but not really 😄 I'm not really opposed to it being a GUID, it just seems so arbitrary (even in CorrelationManager). I mean what's so special about GUIDs anyway - a correlation id is logically an opaque value. So honestly I'm fine either way.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GUIDs actually solve the problem nicely because they have a definite ordering so can be indexed. You can't do that with strings without a lot of ceremony: making sure everything is length-prefixed in storage (nvarchar, but then you kill indexability), making sure everybody agrees on which comparer to use (good luck doing this in SQL), and so on.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That they have a fixed, unambiguous, universal representation is a huge plus over strings, even if ordering doesn't matter. I agree that academically the difference shouldn't matter, but practically it does. I guarantee you'll have a difficult time building a reliable, high-performance correlation engine if your key is an arbitrary structureless string.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most of the time these Ids are persisted as a string always so I'm not sure what you mean. Are you saying if we don't use the .NET Guid type that it won the performant?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The nearly 100% use case is that they're persisted in an ETW log or similar structure, so they're definitely not persisted as strings. Please reread my argument above - I'm not advocating GUIDs for the sake of having GUIDs, I'm advocating it because it's structured, unambiguous, and easy for correlation engines to reason about. If you have another structure in mind that meets these requirements then by all means suggest it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Eilon - Just as a side note. OWIN spec actually says owin.RequestId is a string.

3.2.1 Request Data
owin.RequestId An optional string that uniquely identifies a request. The value is opaque and SHOULD have some level of uniqueness. A Host MAY specify this value. If it is not specified, middleware MAY set it. Once set, it SHOULD NOT be modified.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep I read the OWIN spec 😄 Honestly I'm OK with forcing GUID because there's nothing really wrong with it in practice. It's just kind of annoying when practicality trumps so-called "correctness."

}
}
8 changes: 8 additions & 0 deletions src/Microsoft.AspNet.Owin/OwinConstants.cs
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,14 @@ internal static class OwinConstants

#endregion

#region OWIN v1.1.0 - 3.2.1 Request Data

// OWIN 1.1.0 http://owin.org/html/owin.html

public const string RequestId = "owin.RequestId";

#endregion

#region OWIN v1.0.0 - 3.2.2. Response Data

// http://owin.org/spec/owin-1.0.0.html
Expand Down
7 changes: 5 additions & 2 deletions src/Microsoft.AspNet.Owin/OwinEnvironment.cs
Original file line number Diff line number Diff line change
Expand Up @@ -80,7 +80,7 @@ public OwinEnvironment(HttpContext context)
{ OwinConstants.Security.User, new FeatureMap<IHttpAuthenticationFeature>(feature => feature.User,
()=> null, (feature, value) => feature.User = Utilities.MakeClaimsPrincipal((IPrincipal)value),
() => new HttpAuthenticationFeature())
},
}
};

// owin.CallCancelled is required but the feature may not be present.
Expand Down Expand Up @@ -113,6 +113,9 @@ public OwinEnvironment(HttpContext context)
}

_context.Items[typeof(HttpContext).FullName] = _context; // Store for lookup when we transition back out of OWIN

// The request identifier is a string per the spec.
_entries[OwinConstants.RequestId] = new FeatureMap<IRequestIdentifierFeature>(feature => feature.TraceIdentifier.ToString());
}

// Public in case there's a new/custom feature interface that needs to be added.
Expand Down Expand Up @@ -369,7 +372,7 @@ public FeatureMap(Func<TFeature, object> getter, Action<TFeature, object> setter
}

public FeatureMap(Func<TFeature, object> getter, Func<object> defaultFactory, Action<TFeature, object> setter)
: base(typeof(TFeature), feature => getter((TFeature)feature), defaultFactory,(feature, value) => setter((TFeature)feature, value))
: base(typeof(TFeature), feature => getter((TFeature)feature), defaultFactory, (feature, value) => setter((TFeature)feature, value))
{
}

Expand Down
19 changes: 18 additions & 1 deletion src/Microsoft.AspNet.Owin/OwinFeatureCollection.cs
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,8 @@ public class OwinFeatureCollection :
IHttpRequestLifetimeFeature,
IHttpAuthenticationFeature,
IHttpWebSocketFeature,
IOwinEnvironmentFeature
IOwinEnvironmentFeature,
IRequestIdentifierFeature
{
public IDictionary<string, object> Environment { get; set; }
private bool _headersSent;
Expand Down Expand Up @@ -427,6 +428,22 @@ public bool IsReadOnly
get { return true; }
}

Guid IRequestIdentifierFeature.TraceIdentifier
{
get
{
var requestId = Prop<string>(OwinConstants.RequestId);
Guid requestIdentifier;

if (requestId != null && Guid.TryParse(requestId, out requestIdentifier))
{
return requestIdentifier;
}

return Guid.Empty;
}
}

public bool Remove(KeyValuePair<Type, object> item)
{
throw new NotSupportedException();
Expand Down