- This means connections become untracked sooner than before and not all blocks will
necessarily be returned.
- The assertion in the MemoryPoolBlock2 finalizer was weakened because FilteredStreamAdapter
will continue to use blocks after libuv stops tracking the associated connection.
- Make 100% sure we don't accept new connections after we dispose the listen socket by using a flag.
- Add a (currently unused) AllowStop method to KestrelThread. This is meant to be called from
listeners when we stop accepting new connections, but needs investigation to prevent flakiness.
- Even when safe handles are disposed explicitly, ReleaseHandle is sometimes
called on another thread which breaks uv_close.
- Ensure we close the UvAsyncHandle the uv loop so that the second call
to uv_run always completes without a timeout/Thread.Abort.
- Re-enable some tests. Add skip conditions for those that aren't passing.
- Make the time given for requests to complete gracefully configurable.
- Complete all async reads so calling code can re-check whether to stop
request processing and exit if in between requests.
- Don't wait for a FIN from the client since some browsers (e.g. IE & Chrome)
will take a long time to send one.
- Ensure all ConnectionFilters complete before the memory pool is disposed.
- Ensure blocks get returned even when a ConnectionFilter produces a failed read
Also correct tests to avoid warnings and to ensure scenarios are actually tested
- tests previously went `async` without waiting for completion
nit: add parameter `null` checks
This undoes a behavior change introduced in
7b18d1d3f1.
The intent was to have ClearValidationState do the right thing for a case
where a collection was bound to the empty prefix, and then used again with
TryUpdateModel.
This change was implemented by saying that a key like "[0].Foo" is a match
for the prefix of "Foo". This isn't really right, and it's only
interesting for the ClearValidationState case.
The problem is that we don't know what the keys look like for a
collection. We can assume that they start with [0] but that's not really a
guarantee, it's a guess.
This change fixes the behavior of StartsWithModel, and move the
responsibility for this case back into ClearValidationState.
This change also removes the call to ClearValidationState from
TryUpdateModel. If you need this behavior, then call ClearValidationState
manually. Trying to bind and then re-bind a model object isn't really what
we intend.
This code was popping up everywhere this method is called. Seems bad to
duplicate it. Really what the caller wants to know is 'is the request
valid or a potential CSRF exploit?'. This gets the API closer to that.
Ajay Bhargav Baaskaran
Stephen Halter
N. Taylor Mullen
Nate McMaster
Chris R
ryanbrandenburg
Doug Bunting
Ryan Nowak
Ben Adams
John Luo
jacalvar
Victor Hurdugaci
Kiran Challa
hexelium
David Fowler
SteveSandersonMS
Pranav K
Brennan
Hao Kung