PowerShell: Regression from 7.3.3: Verbose Invoke-WebRequest / Invoke-WebRequest output is missing the byte count

Prerequisites

Write a descriptive title.
Make sure you are able to repro it on the latest released version
Search the existing issues.
Refer to the FAQ.
Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Invoke-RestMethod -Method HEAD http://example.org -Verbose

Expected behavior

VERBOSE: HTTP/1.1 HEAD with 0-byte payload
VERBOSE: received 648-byte response of content type text/html

Actual behavior

VERBOSE: HTTP/1.1 HEAD with 0-byte payload
VERBOSE: received -byte response of content type text/html

Note the missing number before “-byte”.

Error details

No response

Environment data

PowerShell Core 7.4.0-preview.1

Visuals

No response

About this issue

Original URL
State: closed
Created a year ago
Comments: 16 (8 by maintainers)

Most upvoted comments

I found the origin of the problem, it’s a .NET bug Test:

$handler = [System.Net.Http.HttpClientHandler]::New()
$handler.AutomaticDecompression = "All" #<--- BUG ORIGIN
$client = [System.Net.Http.HttpClient]::new($handler)
$message = [System.Net.Http.HttpRequestMessage]::New('HEAD', "http://example.com/")
Write-Output "first: $($client.sendAsync($message).GetAwaiter().GetResult().Content.Headers.ContentLength)" #--> $null or rarely 1258

$handler = [System.Net.Http.HttpClientHandler]::New()
$client = [System.Net.Http.HttpClient]::new($handler)
$message = [System.Net.Http.HttpRequestMessage]::New('HEAD', "http://example.com/")
Write-Output "second: $($client.sendAsync($message).GetAwaiter().GetResult().Content.Headers.ContentLength)" #--> 648 or 1258

http://example.com/ always responds with the same Content-Length (checked with MITM-Proxy), but it’s not reported with $handler.AutomaticDecompression = "All"

Tested in PS 5 - 7.3.3 - 7.4preview1 - latest, the bug is always there

Type	Error
All	Yes
Brotli	No
Deflate	No
GZip	Yes <-- BUG ORIGIN
None	No

</body> </html>

The content-encoding of the website is GZip, it might be related

<div>Example Domain</div>

CarloToso on Feb 28, 2023

So it sounds like we should report it when available, right?

N/A (as @CarloToso suggested):

received response of content type text/html

Available (as before):

received $num-byte response of content type text/html

For the N/A case, I wonder if it’s worth being explicit about not knowing the size; pro: people will know that the information is unavailable; con: they might be wondering why - but that could explained in the docs.

received response of content type text/html of unknown size

mklement0 on Mar 1, 2023

But reports above say that sometimes we get the length.

iSazonov on Mar 1, 2023

Now that we introduced handler.AutomaticDecompression = “All”, we will probably ~~never~~ rarely recieve a content-length header. We should just remove it and change the message to something like #VERBOSE: received response of content type text/html

CarloToso on Mar 1, 2023

Write-Output “first: $($client.sendAsync($message).Result.Content.Headers.ContentLength)”

When calling an async method you should be doing AsyncMethod().GetAwaiter().GetResult(). Doing just .Result is problematic because

PowerShell won’t automatically wait for it to finish
A property getter in PowerShell ignores an exceptions and instead returns null

See https://github.com/PowerShell/PowerShell/issues/19141 for more details.

jborean93 on Feb 28, 2023