Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixing bug around request buffering #1373

Merged
merged 1 commit into from
Feb 9, 2019

Conversation

drub0y
Copy link
Contributor

@drub0y drub0y commented Feb 8, 2019

Fixes #1371

A regression was introduced when support was added in #1352 for a scenario where body stream buffering was enabled. Unfortunately, during that PR, non-buffered streaming scenarios were not regression tested leading to a bug in that (the default) scenario.

The bug was caused by setting Position = 0 on the body stream when non-buffered because, non-buffered streams are not seekable and thus throw a NotSupportedException if you attempt to change their position.

A regression was introduced when support was added in #1352 to support scenario where body stream buffering was enabled. Unfortunately, during that PR, non-buffered streaming scenarios were not regression tested leading to a bug in that (the default) scenario.

The bug was caused by setting `Position = 0` on the body stream when non-buffered because, non-buffered streams are not seekable and thus throw a `NotSupportedException` if you attempt to change their position.
// In the case of request buffering being enabled, we could possibly receive a Stream that needs its position reset,
// but we can't _blindly_ reset in case buffering hasn't been enabled since we'll be working with a non-seekable Stream
// in that case which will throw a NotSupportedException
if (requestBody.CanSeek)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Only attempt to reposition the Stream when it's "seekable". CanSeek will be true in the buffered scenario and false in the non-buffered (default) scenario.

@@ -97,6 +98,14 @@ public void Configure(IApplicationBuilder app, IHostingEnvironment env)
app.UseDeveloperExceptionPage();
}

// NOTE: Uncomment this to force request buffering to test accessing the request body in buffered scenarios (default is always unbuffered)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added this inline middleware to the Test Web App project to facilitate the testing of the two scenarios. I'm leaving it here commented out for the default (non-buffered scenario) and easy uncommenting in the future if the buffered scenario need to be tested again.

@coveralls
Copy link
Collaborator

Pull Request Test Coverage Report for Build 48793

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • 10 unchanged lines in 1 file lost coverage.
  • Overall coverage decreased (-0.06%) to 72.155%

Files with Coverage Reduction New Missed Lines %
/libraries/integration/Microsoft.Bot.Builder.Integration.AspNet.Core/BotMessageHandler.cs 10 0.0%
Totals Coverage Status
Change from base Build 48787: -0.06%
Covered Lines: 3747
Relevant Lines: 5193

💛 - Coveralls

@cleemullins cleemullins merged commit b9762b6 into master Feb 9, 2019
@cleemullins cleemullins deleted the drmarsh/only-seek-bodystream-if-seekable branch February 9, 2019 20:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants