owin.RequestId - new standard key to uniquely identify a request
damianh opened this issue · 14 comments
I would like to propose a new owin key to help correlate a request through the various stages of the pipeline .i.e. Logging.
Name: "owin.RequestId"
Required: yes
Value Description: A Guid that uniquely identifies a request.
I would apreciate this feature on https://github.com/diegobfernandez/WebStats.
With a key per request I could leverage its usefulness
The only arguments I can think of against this idea relate to hammering state on top of a stateless protocol. My argument is a little FUDdy though.
So unique ids per request leads to tracking, tracking leads to new keys like "userId" "formValue", etc..., lots of new keys lead to combing of the new keys into a single key with key-value pairs, a single key with key-value pairs leads to encrypting the single key's value because it might have sensitive data inside of it. What should we call this single key? "ViewState".
Again, I'm acting as the Devil's advocate.
I think that may be a bit of a stretch from this proposal alright :D
In any case, these things should always be chewed on for a while..
If the key only lives for the duration of a request, can it be considered to be persisting state in terms of the protocol?
I like the concept, but I'll quiz you on the details:
- Required: Why should this be required? It does not represent data sent from the client. It is not critical to processing the request. The value is opaque and only requires some level of uniqueness. If it were optional and missing, the first component that wanted to use to could just make up a value and set it.
- Type: Why GUIDs? You want something locally unique, not globally. A GUID is larger and more expensive to create than needed. An incrementing Long would provide the same functionality.
Good thoughts @Tratcher. Echo from me.
Overall, I like the idea and I can imagine some cool uses for it.
First, I hold my opinions weakly in these matters... :)
I suggested required because I wanted it to be a key that could be relied
upon across MW. But optional and popsicle immutable (set once if null)
works too.
Regarding uniqueness, personally I'd at least want it to be unique in a
webfarm. But as you said it's opaque... so perhaps it should be a string
and user gets to choose whether to use a stringified guid or something
faster / locally unique.
On 24 Apr 2014 23:12, "Chris R" notifications@github.com wrote:
I like the concept, but I'll quiz you on the details:
- Required: Why should this be required? It does not represent data
sent from the client. It is not critical to processing the request. The
value is opaque and only requires some level of uniqueness. If it were
optional and missing, the first component that wanted to use to could just
make up a value and set it.- Type: Why GUIDs? You want something locally unique, not globally. A
GUID is larger and more expensive to create than needed. An incrementing
Long would provide the same functionality.—
Reply to this email directly or view it on GitHubhttps://github.com/owin/owin/issues/21#issuecomment-41332913
.
And having it optional and popsicle immutable (by definition) makes it back-compat so owin v1.1 instead of v2...
Is there any reason why any middleware or app needing this functionality should not be able to inject its own middleware to provide that data? if that is the case, then there is no need to make it required, and if we just need to agree on the key and value, i'd support this proposal. I'd prefer owin.correlationId over owin.requestId, as it feels more targetted to the intended usage, but I wouldn't mind enough to make it a deciding factor.
Is there any reason why any middleware or app needing this functionality should not be able to inject its own middleware to provide that data?
Nope.
no need to make it required
Agreed
I'd prefer owin.correlationId over owin.requestId
+0
Spec should state something along these line "A Host MAY specify this value. If it is not specified, middleware MAY set it. Once set, it SHOULD NOT be modified". Or should that be "...it MUST NOT be modified"?
Just a thought, because this isn't strictly to facilitate between host and application, it could go to CommonKeys instead.
+1 for proposing spec language!
-----Original Message-----
From: "Damian Hickey" notifications@github.com
Sent: 5/7/2014 6:40 AM
To: "owin/owin" owin@noreply.github.com
Subject: Re: [owin] New standard key to uniquely identify a request (#21)
Is there any reason why any middleware or app needing this functionality should not be able to inject its own middleware to provide that data?
Nope.
no need to make it required
Agreed
I'd prefer owin.correlationId over owin.requestId
+0
Spec should state something along these line "A Host MAY specify this value. If it is not specified, middleware MAY set it. Once set, it SHOULD NOT be modified". Or should that be "...it MUST NOT be modified"
—
Reply to this email directly or view it on GitHub.
+0
Moved to owin/owin#8 , please discuss there.