This takes PathNormalizer from Kestrel to normalize the request path and prevent traversals. (e.g. "/./" and "/../").
In 2.1 only HttpSys was affected. In 2.2 HttpSys and IIS-in-proc will share this code (with additional tests). In 3.0 we'll refactor it to use more shared source across all three servers.
- correct `--filter` syntax; perform `contains` match on `Name` and not `FullyQualifiedName`
- `FullyQualifiedName` doesn't seem to include NUnit test case data
- move to latest test package versions
- support recent SDK versions
Background: successful but no-op builds have been common lately
- blocking real work on aspnet/AspNetCore-Internal#1843
- aspnet/AspNetCore-Internal#1649
- remove `$(StartArguments}` from project; conflicts with `--update`
- support v3 source _automatically_ when not using `--update`
- use NuGet's V3 source by default
- update README.md
nits:
- `--source` -> `--package-source` due to conflict with a `dotnet` argument
- address Markdown lint warnings in README.md
- grab a couple of improvements from 'release/2.2'
- never exit silently
- remove `first` special case
- aspnet/AspNetCore-Internal#2231
- use internal pools for all internal builds
- do not sign in builds for internal pull requests
nits:
- VSTS -> Azure DevOps
- restore higher `maxParallel` values for E2E tests on Linux and Windows
* Ensure PackageArchive contains the right build of Razor.Design package
* Re-order values in build\dependencies.props to ensure Razor.Design's package version is
overwritten.
* Convert additional package refs to project refs
Fixes https://github.com/aspnet/AspNetCore-Internal/issues/1708
* Update CodeCheck.ps1
Possible fix to https://github.com/aspnet/AspNetCore/issues/7313
One of the characteristics of these failures were that the
test took long to run. The build log has warnings for
several long running tests. This might be a result of CPU
contention since mondo-ification that make MVC's functional tests
run with nearly every other test project in the solution
* Add some additional logging to ErrorPageMiddlewareWebSite
DeveloperExceptionMiddleware will log an error if rendering the exception page
throws. The test failure in https://github.com/aspnet/AspNetCore-Internal/issues/1730
suggests that we encountered an error like so but do not have anything further to go by.
This change adds logging to the test so we could identify possible issues
Pranav K
dotnet-bot
Matt Mitchell
Chris Ross (ASP.NET)
John Luo
Nate McMaster
Doug Bunting
Doug Bunting
Javier Calvarro Nelson
Brice Lambson
Brennan Conroy
Stephen Halter
Mikael Mengistu