* Add -SkipHttpErrorCheck to web request cmdlets
The -SkipHttpErrorCheck flag causes web request cmdlets
(Invoke-WebRequest and Invoke-RestMethod) to ignore HTTP statuses that
are error statuses and treat them as successful requests. This allows
users to handle the responses using their own error handler and gives
them access to the full, unmodified response body and headers.
* Add -ResponseStatusVariable to Invoke-RestMethod
This allows the user to specify a variable to set to the integer value
of the respons's status code, Analogous to using
-ResponseHeadersVariable to retrieve the headers of the response. This
can be used to distinguish error messages from success messages when
used with -SkipHttpErrorCheck.
* Fix coding-style error
The summary for the SkipHttpErrorCheck property didn't conform
to style guidelines. This changes the summary to start with
"Gets or sets".
* Add tests for -SkipHttpErrorCheck
This flag supresses terminating errors on web cmdlets.
The tests are written to check that it properly
supressed the errors.
* Add test for -StatusCodeVariable
Th -StatusCodeVariable parameter specifies an output
variable for the status code with Invoke-RestMethod.
This test makes sure it functions properly.
* Fix typos and style for -SkipHttpErrorCheck tests
Variables had different cases from each other and some parameter
names were lower case.
* Fix typos and style for -StatusCodeVariable test
Variables had different cases from each other and some parameter
names were lower case.
* Add failure tests when missing -SkipHttpErrorCheck
These tests ensure that Web Cmdlets fail when -SkipHttpErrorCheck
is missing.
* Clean up tests for -SkipHttpErrorCheck
Per discussion on the pull requests. This commit fixes up
style problems with the tests for -SkipHttpErrorCheck.
* Add more status tests for -StatusCodeVariable
Previously, the -StatusCodeVariable flag in Invoke-RestMethod
only had tests for 200 status. This commit adds tests for 404
and 500 statuses and removes -SkipHttpErrorCheck from the 200
check.
* Fix response body in -StatusCodeVariable test
The test was copy/pastes from the 200 status test. The body
indicated success. This commit fixes that so it is also an
error indicator.
Instantiating a new MediaTypeHeaderValue object fails when the -ContentType parameter includes a charset such as application/json; charset=utf-8. This makes it impossible to set the content encoding on web requests. Moving to Parse() ensures we actually get a proper MediaTypeHeaderValue when the charset is present, thus allowing users to set their request encoding via proper -ContentType values.
Web Cmdlets will no longer forcibly remove Expect: 100-continue from web requests.
This was a legacy setting that needed to be there because of platform differences that have since been resolved in CoreFX.
WebListener.exe (which was already being built) is sufficient to start web listener. Remove the dependency on `dotnet` being present to start the web listener.
Use `Start-Process` instead of `Start-Job` to launch the WebListener.
Update links that contain 'en-us' culture to remove 'en-us' culture (if possible) and in some cases update to newer re-directed link to docs.microsoft.com
Convert ShouldBeErrorId to Should -Throw -ErrorId in PowerShell tests.
Get rid of try { } catch { } formula to assert that errors were thrown.
Small fixes in tests to obey the new Pester -Parameter syntax.
closes#6728
Breaking change approved in #6728
This PR switches the logic of when the Web Cmdlets handle redirects when the Authorization header is present. .NET Core 2.1 no longer sends the Authorization header by default (dotnet/corefx#26864). however, we introduced the ability to do so leveraging the previous default behavior through the use of the -PreserveAuthorizationOnRedirect switch.
This PR also corrects a bug introduced 6.0.0 where certain redirect types redirect from POST to GET were set which should have passed through POST to POST and some were improperly passing through POST to POST which should have been doing POST to GET. This correction is a breaking change. It was made apparent as now the redirection behavior is being managed by CoreFX which is doing the correct behavior, tests were added for both when CoreFX and the Web Cmdlets manage redirection.
* Build Update
- Change `TargetFramework` to `netcoreapp2.1` and removed unnecessary `RuntimeFrameworkVersion` from `PowerShell.Common.props`
- Update dotnet SDK to 2.1.300-rc1-008662
- Update `TypeGen` target in `Build.psm1` to work with 2.1
- Rename macOS runtime to `osx-x64` as the old build logic expects 10.12 and breaks running on 10.13 system.
- Remove `PackageReference` to `System.Memory` as it's part of dotnetcore 2.1
- Update search for `crossgen` executable to find the matching version
* Test Update
- Update test tools `WebListener` to latest `asp.net core`
- Marked `AuthHeader Redirect` tests as `Pending` due to change in CoreFX
The HTTP RFC (https://tools.ietf.org/html/rfc7231#section-6.4) does not require a Location header to be present for redirects, thus it is required to check if the Location header is returned before using it.
Fixes#5964
Adds -Resume switch to Invoke-WebRequest and Invoke-RestMethod
-Resume requires -OutFile
Enables the ability to resume downloading a partially or incompletely downloaded file.
File Size is the only indicator of local and remote file parity.
If the local file is smaller than the remote file and the remote endpoint supports resume, the local file will be appended with the remaining bytes.
If the local file is larger than the remote file, the local file will be overwritten
If the remote server does not support resume, the local file will be overwritten
If the local file is the same size as the remote file, the remote endpoint will return a 416 status code. This response is special-cased as a success in this instance. The local file remains untouched and it is assumed the file was already successfully downloaded previously.
If the local file does not exist it will be created and the entire remote file will be requested.
Added tests for all code new code paths (I'm pretty sure anyway)
Added /Resume Controller to WebListener
Documented /Resume Controller
Updated .spelling to reflect terms in WebListener docs
Note: I had to change the way GetResponse() tracks the current URI as we now have 3 places where the call is taking place. I don't foresee this causing any regressions. This area needs some refactoring. especially if we want to implement a retry mechanism
When a charset is not supplied for a JSON response, the default encoding should be UTF-8 per RFC 8259. This commit changes the default charset to UTF-8 for JSON responses when a charset is not defined.
Based on standard practices, we need to have a copyright and license notice at the top of each source file. Removed existing copyrights and updated/added copyright notices for .h, .cpp, .cs, .ps1, and .psm1 files.
Updated module manifests for consistency to have Author = "PowerShell" and Company = "Microsoft Corporation". Removed multiple line breaks.
Separate PR coming to update contribution document for new source files: #6140
Manually reviewed each change.
Fix#6073
Change Web Cmdlets Tests to Use 127.0.0.1 instead of localhost due to dotnet/corefx#24104
This provides a decent speed boost to the WebCmdlet tests (Faster in dozens of times).
- Adds -Form Parameter to Invoke-WebRequest and Invoke-RestMethod.
- Form Accepts any IDictionary.
- Keys are used as multipart/form-data field names (PSObject unwrapped and ConvertTo<String>(Object)).
- FileInfo values are added as StreamContent with application/octet-stream content type and the FileInfo.Name as the file name.
- Strings are treated as StringContent.
- Singe values are converted to string with ConvertTo<String>(Object) and treated as StringContent
- Top level collections are enumerated and converted as above. Nested collections are treated as a single value and converted accordingly.
- Form is mutually exclusive with -Body and -InFile.
- Per PowerShell-Committee decision, -Form makes no assumptions about the HTTP method used. It can theoretically be used with any method. User will need to manually supply -Method POST to post the form.
- ContentType and content related headers supplied to -Headers will be ignored/cleared as MultipartFormDataContent requires control of these headers.
- Add Link controller to WebListener
- Replace HttpListener Link tests with WebListener
- Update WebListener Documentation
- Enable cross-platform multiple Link header tests
•Replaces all remaining test that rely on httpbin.org
•Adds Put, Post, Patch, and Delete tests to WebListener by means of routes to Get test and modifications to the Get controller.
•Adds responsephrase option to the Response test to accommodate error message tests
•removed redundant GET tests from irm and iwr tests.
•Fixed markdown linting errors in README.md for WebListener
closes#2662
This feature adds the ability to restrict the SSL/TLS protocol used when making the web request. In 5.1 the user could make use of .NET API's to enforce this on the Web Cmdlets. With the move to HttpClient in PowerShell Core, those APIs have no impact. The user still has requirements to ensure specific protocols are used.
The public enum WebSslProtocol is added as a wrapper to the underlying SslProtocols enum. Neither it nor SecurityProtocolType can be used because Ssl3 and Ssl2 are not supported by HttpClientHandler.SslProtocols. While it may not be intuitive to a PowerShell user to use -bor or "Tls, Tls11" to set multiple options, the general use case for this will be a single protocol.
Adds -SslProtocol parameter to Web Cmdlets
Adds WebSslProtocol Enum to support limited subset of SslProtocol enum supported by HttpClientHandler
Adds TLS 1.1 and TLS 1.0 listening ports to WebListener
- Add an error when a user tries to use `-Credential` (legacy usage without `-Authentication`) or `-UseDefaultCredentials` over a non-HTTPS URI
- User can bypass error with `-AllowUnencryptedAuthentication`
- `-UseDefaultCredentials` can only be reliably tested on Windows as support on other platforms depends on a Kerberos infrastructure.
- Add `/Auth/` tests to WebListener for challenge authentication Basic, Negotiate, and NTLM
Incidentally, this increases test coverage for the web cmdlets as `-Credential` and `-UseDefaultCredentials` were not being tested.
Closes#4274
Adds an -Authentication parameter to Invoke-RestMethod and Invoke-WebRequest
Adds an -Token parameter to Invoke-RestMethod and Invoke-WebRequest
Adds an -AllowUnencryptedAuthentication parameter to Invoke-RestMethod and Invoke-WebRequest
Adds tests for various -Authorization uses
-Authentication Parameter has 3 options: Basic, OAuth, and Bearer
Basic requires -Credential and provides RFC-7617 Basic Authorization credentials to the remote server
OAuth and Bearer require the -Token which is a SecureString containing the bearer token to send to the remote server
If any authentication is provided for any transport scheme other than HTTPS, the request will result in an error. A user may use the -AllowUnencryptedAuthentication switch to bypass this behavior and send their secrets unencrypted at their own risk.
-Authentication does not work with -UseDefaultCredentials and will result in an error.
The existing behavior with -Credential is left untouched. When not supplying -Authentication, A user will not receive an error when using -Credential over unencrypted connections.
Code design choice is meant to accommodate more Authentication types in the future.
Documentation Needed
The 3 new parameters will need to be added to the Invoke-RestMethod and Invoke-WebRequest documentation along with examples. Syntax will need to be updated.
Vincent Damewood