@iSazonov ready to review!

EDIT: I lied, but now codefactor stuff is fixed.

I wonder how many code you update. 😄 I expect you add only content output.

I like you create helper methods. But now output is too large and we must generate the output only it is requested.
I don't find method(s) to check the condition and we could create it here.
For start see how internal void WriteDebug(DebugRecord record, bool overrideInquire = false) does the check.
We can get ((MshCommandRuntime)this.CommandRuntime).DebugPreference and reuse code from internal bool WriteHelper_ShouldWrite
(All in src\System.Management.Automation\engine\MshCommandRuntime.cs)

The same for verbose. But I wouldn't waste time on verbose right now at all. But it's up to you.

Also I'd prefer to use standard TosString() for request and response. Why do we create custom implementation?

@iSazonov I had this discussion with @SeeminglyScience on discord and it is noted there isn't an ideal reliable way to check preference (if you check the first commit I was testing for it prior) and he recommended not establishing it as a pattern but rather this should be something the runtime provides as part of the PSCmdlet abstract class.

In testing the code has a non-visible impact even on large payloads if Verbose/Debug aren't specified.

I moved away from the Request/Response message toString in order to match the format as noted, and reduce redundant information between Verbose and Debug. I put the user experience in favor of the direct implementation. We can revert that if required, but I would lobby for this, especially since I try/catch potential edge cases (haven't hit any so far in testing)

EDIT: Also I made very sure not to alter existing Webcmdlet behavior, the additional areas I changed were just additive where they made sense in context, I'm very aware this is some hot-path stuff and I'm keeping the scope just to the output aspects.

@JustinGrote Yes, we haven't std methods for the checks. I think it's important to have them because later we can add even more output (for example certificates)
One way is to create them. So I open #25514. If you could ask him in Discord to review it, that would be great.
Another way is to use simple workaround only for interactive scenario. We could check switches by more reliable way than you did - Debug.IsPresent/Verbose.IsPresent. We could use this if my PR will be blocked/rejected.

Sounds good. Do we want to merge this PR as-is for the next preview and add the conditional logic later, or wait for #25514?

Let's wait for what Patrick says. If that PR is not approved, then let's look at switch checks. What I definitely would not like is to create these strings without a condition.
We can discuss the details for now.

@iSazonov thank you for the review, I will incorporate the recently merged PR and your feedback hopefully sometime this week.

@iSazonov feedback incorporated and it is now conditional using the new internal IsEnabled checks

@iSazonov changes requested implemented (I went with a nested foreach for the headers to make that easier to read), and made CodeFactor happy. I also squash rebased to a single commit so this should be mergeable now. Let me know any further issues.

@iSazonov static refactor reverted. CodeFactor however is now complaining about complex methods I didn't touch. I tried a rebase/reset and confirmed I didn't touch those methods as far as I can tell. Any idea what's going on? Is it the nullable maybe?

@iSazonov incorporated feedback. Codefactor still complaining about complex methods I didn't touch.

@iSazonov incorporated feedback. Codefactor still complaining about complex methods I didn't touch.

@JustinGrote Please ignore such issues.

I'll investigate the test failures.

@iSazonov good catch, that was it. Wonder why it is disposed though? It was literally assigned just prior, it wasn't a scoped using or anything I can see. Also fixed an inconsistent Write method name

@iSazonov I rebased to latest master and I think that made codefactor mad, you probably need to exclude whatever you did previously for the complex methods.

I rebased to latest master and I think that made codefactor mad, you probably need to exclude whatever you did previously for the complex methods.

Line 1416 currentRequest.Dispose();

@JustinGrote I see some tests still hang ...

@iSazonov I was having trouble getting my local testing to work specifically for webcmdlets last night but I will try again this evening (US Pacific time)

@iSazonov tests fixed (at least locally on my machine), the -Debug parameter was causing inquire and since Pester is run interactively, was waiting on the dialog, switched to using debugpreference.

Also adjusted encoding test to match on Codepage since we are providing it anyways, should be a much less brittle test.

@JustinGrote Still hang. I guess VerbosePreference is inquire.

Probably related to this, I couldn't get it to reproduce in Linux but let me do it in Windows.