owin / owin.dll

OWIN defines a standard interface between .NET web servers and web applications.

owin


owin.dll's Issues

server.User common key

I'm just going to make this statement for discussion purposes and does not imply I agree with it :)

server.User which is a ClaimsPrincipal has become the defacto standard key for identifying a user in a request pipeline. It should be at least added commmon keys.

owin.RequestId - new standard key to uniquely identify a request

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.

AppTaskDelegate return value (tuple vs value-type)

option a - in code

• Task<Tuple<string, IDict<string,IEnum<string>>, BodyDelegate>>

option b - for consideration

• Task<OwinResponse>; struct OwinResponse { string Status, IDict headers, BodyDelegate body }

Environment key "owin.TraceOutput"

Based on Rack's "rack.output" key - this would be a host-provided TextWriter that logging output could be directed onto.

This enabled a developer of an owin web site to have a consistent and host-agnostic place to direct runtime or diagnostic information.

For console application hosting this would map directly onto stdout. For aspnet this could be directed any number of places. Trace.WriteLine for example? If a company is providing shared web hosting is OWIN-aware, they may introduce their own TextWriter object for trace output, which could direct logging output into a system the client could access via control panel or other means.

AppDelegate fault action

option a - draft 5 and in code

• AppDelegate has a third, fault action passed in

option b - for consideration

• fault action added to environment because it's passed all over the place

option c - for consideration

• merge result and fault actions in AppDelegate, so ResultDelegate would have a nullable Exception argument added

Submitted by Duncan Pierce:

It would be interesting to see how things work out if the fault action were attached to the environment rather than passed as a parameter to the app delegate. We've evolved our own framework of wrappers that work as extension methods around the delegates, which probably biases our view. What we find is that fault gets passed around a lot and yet is hardly ever used in our code. (The framework code does use it though and could in most cases pick it up from environment without user code having to pass it).

Contributor agreement sender missing

I've printed, completed an signed the contributor agreement.

Please provide an address to send PDF.

Regards,
Giacomo Stelluti Scala

Startup context (do nothing vs builder.Properties)

option a - in code

• nothing, context at startup is application-specific solution

option b - for consideration

• IDictionary<string,object> IAppBuilder.Properties for intra-component (host/middleware/fwk/site) context at startup

Unify Request and Response representation

option A - do nothing, call env dictionary in and response arguments and tuple out is fine

option B - represent as incoming app(a,b,c) args, outgoing result(a,b,c) args and return task<tuple<a,b,c>>

option C - represent as incoming value-type app(callparams), outgoing result(resultparams) and task

option D - represent as incoming app(idict env), outgoing idict result(idict resp) and task

Note - this topic combines and unifies the two topics #4 and #5

App/Middleware delegate should take Next delegate parameter

The App/Middleware delegate signature should be:

Func<IDictionary<string,object>, Func<Task>, Task>

Similar to Node.js Connect

This would provide a much clearer way for

1. Application delegates to say "I don't know what this is", or,
2. Middleware to integrate itself into the pipeline - see this blog post.

Some would say that changing the delegate at this stage would be deleterious to the fledgling ecosystem, but it seems that most of the work has currently been done around Katana and IAppBuilder, which adds so much to the base spec that I don't really think changing the core delegate would have a huge effect.

Adding more response properties, e.g. httpversion, trailing headers

Introduced in discussion thread:
https://groups.google.com/d/topic/net-http-abstractions/rHqZaBHAcAo/discussion

Option A - add as additional arguments to ResultDelegate(...) as well as to AppTaskDelegate's Tuple<...>

Option B - add as additional keys to call env dictionary as response is returned

Option C - add as a single, open idictionary to ResultDelegate(...) as well as to AppTaskDelegate's Tuple<...>

Option D - change entire response to open idictionary in ResultDelegate(...) as well as AppTaskDelegate's Tuple<...>

Environment key "owin.HttpVersion"

Probably a value like "HTTP/1.0" or "HTTP/1.1"

Because OWIN allows such low-level control there are situations where you will likely need to know what protocol you are executing on, in order to respond exactly as the caller expects.

Use github issues for voting on proposals

Create a label called 'proposal' for initial.. proposals. When enough discussion / lamenting / gnashing of teeth has occurred, the management committee can move the issue to vote stage by using the vote label if appropriate. We also should leverage milestones feature to associated proposals with versions of the spec.

AppDelegate's ResultDelegate arguments (args vs value-type)

option a - in code

• result(string, IDict<string,IEnum<string>>, BodyDelegate)

option b - for consideration

• result(response); struct OwinResponse { string Status, IDict headers, BodyDelegate body }

Environment key "owin.CallDisposed"

There's an ad-hoc key "host.CallDisposed" with a CancellationToken that will be signalled when a request/response cycle is entirely complete.

That is incredibly convenient for distributed cleanup. A framework could use register with this token to perform IoC container Per-Request scope disposal.

request & response headers (concat vs enumerable vs array)

option a - draft 5

• IDictionary<string,string>

option b - in code

• IDictionary<string,IEnumerable<string>>

option c - for consideration

• IDictionary<string,string[]>

BodyDelegate - what should the write operation look and work like

BodyDelegate transmit calls (joined vs split)

option a - draft 5

• isasync = write(data, ()=>continue);

option b - in code

• isbuffering = write(data); isasync = flush(()=>continue);

option c - for consideration

• return to single write operation, but add the flush semantics

Consensus is option C

Move IAppBuilder to Microsoft.Owin

IAppBuilder is not part of the OWIN spec and should not be included in an owin.dll. This just confuses people new to OWIN.