-
Notifications
You must be signed in to change notification settings - Fork 19
Meeting 27 jun 2012
-
Status update on OWIN + Gate updates
-
Request and response body format
Changes from previous changes are pushed to Owin.dll on myget.org
The Gate solution is in the process of changing
Conversation framed - can you get to underlying body request or response stream?
Some options exist to have both delegate and stream present, but all have disadvantages.
Using stream to represent the request body has some trade-offs, but doesn't seem to have any critical disadvantage.
The most likely way to represent the response will be an action of stream
That would likely be Action<Stream, CancellationToken, Action<Exception>> where the Stream replaces the "write/flush" lambda
To err on the side of future compat, that would be Func<Stream, CancellationToken, Task>
Compat with .NET 3.5 would likely be a secondary concern and could be done with a different functional representation if and when needed
CancellationToken in particular would need a different legacy representation
Leaning more heavily on Task
Primary form of AppDelegate would also benefit from returning Task instead of having two forms, one of which is a callback with optional exception
Should also include the AppDelegate CancellationToken in the CallParameters, and clarify the "Completed" semantics in that it is guaranteed to be triggered by the serve once the call has completed
There is also a KatanaProject on Codeplex that will be flipped to public soon
Chris is starting a process of updating the text of the spec
The common keys aren't documented yet
Non-OWIN server non-specific keys are prefixed with "host.KeyName", like "host.TraceOutput"
Server specific keys are prefixed with the server's name "kayak.KeyName", "httplistener.KeyName"
If a .NET type is used as a specific env entry the fullname may also be used, such as "System.Web.HttpContextBase"
ServerVariable ISAPI/CGI-style keys are currently prefixed with "server.KeyName", like "server.CLIENT_IP"
The "server." keys should possibly be unprefixed, like "CLIENT_IP", because hosts that are copying them verbatim rom a dictionary would be doing string allocation and manipulation for no particular reason.
It may also be good to have an addendum to owin for additional keys.
A conversation should be started on the thread for input about common keys