Currently, the InputManager uses a bunch of mappings in the static KeyHandlers class to make sure that unrecognized keystrokes (for instance, the media keys, the browser control keys, etc) don't cause anything to print in the REPL. For instance:

This became apparent when trying to move the Microsoft.Repl project to netstandard1.3, where most of those ConsoleKey values don't exist (they're in netstandard2.0 and in netcoreapp2.X and above).

There are other keys that aren't in the current ConsoleKey and would cause this, they're just rare. But the netstandard1.3 change makes that set of keys much larger and more likely to be hit (even accidentally).

We need a better way to handle the full set of otherwise-unhandled unprintable characters. As I mentioned in #117 (comment), one option would be to have our own char.IsPrintable( ... ) implementation, based on something like IsLetterOrDigit || IsPunctuation || IsSymbol || Environment.NewLine || ' ' but we would need to take care to get that right. Once we had that, if the ConsoleKey wasn't handled by KeyHandlers, and the character for that key didn't meet our definition of printable, then we could safely just ignore it.

I'm putting this issue in here to track this work since I think it is separate from the conversion of the library to netstandard1.3, but still very important.

What magic incantation do I need to add to the launchSettings.json file to add the HTTP REPL as an option to launch the app? I'd prefer this because it's not a manual thing that we have to do in Visual Studio, plus some developers might be using VS Code. I initially tried:

// The HTTP REPL must be installed.
// dotnet tool install -g Microsoft.dotnet-httprepl
"HTTP REPL": {
    "commandName": "Executable",
    "executablePath": "dotnet",
    "workingDirectory": "$(ProjectDir)",
    "commandLineArgs": "httprepl https://localhost:5001",
    "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
    }
}

However, this starts the REPL correctly but not the site itself. Is there a way to do both?

In bash (at least), typing ctrl+r enters a reverse-i-search mode that allows you to search through your command history based on a search pattern. The use case here could be something like (just for a rough idea, not intended to work exactly this way):

Initially execute these commands:

connect https://localhost:443/
cd values
post -body 5
post -body 7
post -body 10
get 5
post

then you type ctrl+r, followed by p. You'll be presented with the most recent matching command you executed (post) - subsequent presses of ctrl+r would move backwards through the command history displaying matching commands. Once you've got the one you want, you can hit enter and it will execute it. Typing characters does not edit the select command - it appends to the search string.

Would people find this useful?

Great project,

as an idea, could you add an appropriate extension to the temp file name, so that an editor can provide colouring and intellisense for the body template?

Should be here:

Thanks!

Currently, the HelpCommand has three main code paths when executed:

1. If you just say help, it displays a canned and curated lists of commands and their help summaries
2. If you say help <command> [<subCommand>], where is whatever command you're interested in and is an optional subCommand for the command, then you'll get the detailed help for that command (assuming it exists).
3. If you say help <relativeUrl>, where is a path to a known api endpoint, it displays a more verbose version of what you would have gotten if you (starting at the root) did cd <relativeUrl> followed by ls. Note that this relativeUrl is always relative to the root, not to the current directory.

For this issue I'm proposing splitting off that third option since it seems to be in the wrong place, and instead making an optional subcommand or argument on the ls command, something like ls verbose that displays the information in the same format as the current help implementation does, but following the semantics of the current ls command where it looks at the current directory.

Not saying this needs to be done now, Just wanted to put an issue out there to track it.

cc @jimmylewis @bhsubra @jodavis for your thoughts.

Right now, if you execute any of the following almost-legitimate commands:

PATCH --help
PATCH help
PATCH "{'productId': 5}"

You just get some generic help text, such as:

UnknownOption -- --help
Usage: PATCH [Options]

Issues a PATCH request.
Your default editor will be opened with a sample body if no options are provided.

But it does not tell you what [Options] can be.

If you manage to issue the correct help command:

help patch

then you'll get something more helpful:

Usage: PATCH [Options]

Issues a PATCH request.
Your default editor will be opened with a sample body if no options are provided.


Options:
    --header|-h
    --response
    --response:headers
    --response:body
    --no-formatting|-F
    --streaming|-s
    --no-body
    --file|-f
    --content|-c

But even that could use some work. For instance, what's the correct way to pass json as inline content, given that json will almost certainly have double-quotes in it? What do any of those other options even mean?

Currently, the default value of the User-Agent header is set to HTTP-REPL here:
https://github.com/aspnet/HttpRepl/blob/b208ca44a4f9361027b42df89a79594c291b72a5/src/Microsoft.HttpRepl/HttpState.cs#L45

You can override it using the various methods of setting headers, but it would be nice to have this pulled from preferences so if you, for instance, always wanted to be emulating a particular User-Agent, you could have that persist.

Environment

dotnet --info Output:

.NET Core SDK (reflecting any global.json):
 Version:   2.2.100-preview2-009404
 Commit:    f4707d384d

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /home/jesse/dotnet/sdk/2.2.100-preview2-009404/

Host (useful for support):
  Version: 2.2.0-preview2-26905-02
  Commit:  ad4d306fe0

.NET Core SDKs installed:
  2.2.100-preview2-009404 [/home/jesse/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.2.0-preview2-35157 [/home/jesse/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.2.0-preview2-35157 [/home/jesse/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.2.0-preview2-26905-02 [/home/jesse/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Note: dotnet points to preview version on my machine.

Slow terminal printing

1. I installed latest dotnet-httprepl with this command:
   dotnet tool install -g dotnet-httprepl --version 2.2.0-preview3-35246 --add-source https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

2. I created and ran a default webapi project: dotnet new webapi && dotnet run

3. I spun up dotnet-httprepl with dotnet-httprepl --help

The usage printed to the screen one line at a time extremely slowly. I timed it and it takes a full 10 seconds to print to the terminal.

Duplicated characters

The second issue is when I open a repl session, typing results in duplicate characters to be printed to the screen:

1. Run httprepl with dotnet-httprepl http://localhost:5000

jesse@xubuntu:~/git $ dotnet-httprepl http://localhost:5000
(Disconnected)~ set base "http://localhost:5000"

http://localhost:5000/~ lls

http://localhost:5000/~ II  am ttypiing a senttencce

No matching command found
Execute 'help' to se available commands

http://localhost:5000/~ II  aam  ccarefully ttypingg  tthis..  Myy  kkeyboard is not brokenn.e

No matching command found
Execute 'help' to se available commands

http://localhost:5000/~ sset  bbaase  hhttttppss::////lloocalhost::550001

https://localhost:5001/~

As you can see, it still understands the commands that are being typed, so I think it's just a display issue.

Also that string "Execute 'help' to se available commands" was copied verbatim from the output.

I'm looking forward to using this tool in my development! :)

Inform user swagger document not set when ls is run without document set.

It would be nice to be able to see rough timing measurements for the various API calls.

I don't believe the intention here is to really have strong metrics on the performance. But rather something more akin to the timing information given in Visual Studio when you allow the debugger to execute a line of code and it tells you how long it took. You'd be looking to make sure something wasn't taking 10s when you expect it to take 1s, rather than trying to nail down the difference between 10ms and 20ms.

We should force the display of the HTTP verbs in upper case. The spec says they're case-sensitive so we should at least display them that way, even if we allow lower case when they are executed with our internal commands.

Is it on your roadmap to support authorization headers, and possibly to support OpenID Connect standards based implicit flow authentication through a browser popup?

The user will see a Win32Exception bubble up to them if they've set the default editor to something that doesn't exist:

System.ComponentModel.Win32Exception (2): The system cannot find the file specified.
   at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
   at System.Diagnostics.Process.Start()
   at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
   at Microsoft.HttpRepl.Commands.BaseHttpCommand.HandleRequiresBody(DefaultCommandInput`1 commandInput, IShellState shellState, HttpState programState, HttpRequestMessage request, Dictionary`2 requestHeaders) in /_/src/Microsoft.HttpRepl/Commands/BaseHttpCommand.cs:line 224
   at Microsoft.HttpRepl.Commands.BaseHttpCommand.ExecuteAsync(IShellState shellState, HttpState programState, DefaultCommandInput`1 commandInput, ICoreParseResult parseResult, CancellationToken cancellationToken) in /_/src/Microsoft.HttpRepl/Commands/BaseHttpCommand.cs:line 122
   at Microsoft.Repl.Commanding.DefaultCommandDispatcher`2.ExecuteCommandInternalAsync(IShellState shellState, CancellationToken cancellationToken) in /_/src/Microsoft.Repl/Commanding/DefaultCommandDispatcher.cs:line 150
   at Microsoft.Repl.Commanding.DefaultCommandDispatcher`2.ExecuteCommandAsync(IShellState shellState, CancellationToken cancellationToken) in /_/src/Microsoft.Repl/Commanding/DefaultCommandDispatcher.cs:line 113

A common way that this might be hit is if they try to just set the editor to code since that's what they'd issue at the command line to open VS Code:

pref set editor.command.default code

That won't work - they need to put in the full path. But that's just an example. We should give a better message to the user and not just throw out the Win32Exception here.

If the API does not accept a HEAD request for the "set base" URL and returns a 404 then the REPL errors out with a StackOverflowException. ("Process is terminating due to StackOverflowException.")

The base URL should probably accept a HEAD request? But, in case it does not, like the one I was trying, may be a more meaningful error will be helpful.

Even though the base URL returned a 404, REPL still makes a request to a default swagger URL and in my case, that did return 200. So may be if both return 404 only then return an error?

Was able to observe this behavior with Fiddler as follows:

λ dotnet --version
2.2.100-preview2-009404

Also, Some of the keywords for HELP seem to be missing when I tried it out. I tried it in regular CMD prompt as well and got the same result.

Currently there are three end point metadata readers:

1. OpenApiV3EndpointMetadataReader
2. SwaggerV1EndpointMetadataReader
3. SwaggerV2EndpointMetadataReader

We need to create site for each of these endpoints and validate the expected schema. We also need to document the same.

When entering an incorrect command, usage is printed. The usage is printed in a different color, and the color doesn't reset before printing the next prompt.

For example, when omitting the header value after -h in the following sample

There's a bug in the json parser for the OpenAPI V3 reader that causes it to not detect schemas for request bodies that are present in the OpenAPI definition. This causes the example request body to always be blank, even when the definition gave us the information we needed to provide one to the end user.
This is probably the root cause of #131 which we didn't, at the time, have a repro for.

It looks like SetHeaderCommand is just coded to return the help regardless of whether the input to it is valid. So when the help command iterates through the commands looking for the first one that is valid, SetHeaderCommand returns a value when it shouldn't.

Should be self-explanatory from the title.

Here are the items I noted as we went through the review:

• Content-Type. Maybe Configurable default or infer
• Print headers command (or show them somewhere)
• Ensure set header supports : as well as =
• Currently hangs when try to use http for app using redirects to https
• Check base url when setting so that you don't feel dumb
• Things that return a straight up string get the streaming notification text
• Body on delete bug
• Put the verbs for the current location on .

@mlorbetske

• Try http and https when given base with no scheme
• Post to values controller [FromBody] requires quotes: https://localhost:44338/api> post -c 'value' -h Content-Type:application/json values

@glennc

• Colors in blue powershell are bad
• Typo in the help for run
• Help text for post command on its own
• Clearer delimitation of when the raw response ends and when CLI formatting starts (newlines)
• Help still needs more formatting and content

Future:

• Allow full text request syntax in text file
  a. Support .HAR file, export from browser run in CLI.
  b. Support psuedo HTTP request in editor so headers and such can be specified
• Copy more output format of LS from cmd and powershell
• Turn on timings
• consider making commands appear on a new line

@mlorbetske I think you fixed some/all of these as we sat there. Right? I can't remember what all of them are now so I intended to go through and check them off as I worked out my own notes.

The idea would be to have a command that allows you to save all of the commands you've issues in your session thus far into a file - one that you could tweak and reuse with the run command later.

For instance, if your scenarios requires a bunch of headers to be set before you execute your API, you could do it once interactively, making sure it works, then use this new command to save your session to a file. You can then tweak it to remove the commands you used to validate it worked, and it'll be ready to be used with the run command in future sessions to make the setup easier.

We need to revisit and clean up MockHttpMessageHandler based on this comment:
#115 (comment)

in PR:
#115

One time it comes through colored, one time it doesn't.

When users use the backspace keystroke when in the tool to backspace over previously-written content, the icon changes to the "lock" icon, which to a MacOS user is usually a cue that they need to enter their password. The gif below shows the issue in practice.

This is a disruptive experience.

In general, some more polish on the colorization could be helpful in making the output of the tool more readable. This might include (in no particular order):

• Better/more colorization/bolding
• Theming support
• Better spacing, indentation and use of whitespace
• Changing layout of output (particularly from dir/ls commands) and the way we identify things (is the ./.. notation sufficient?)

As I'm working in an enterprise environment I would like to be able to turn on UseDefaultCredentials=true on HttpClient.

Most of our HTTP endpoints use Kerberos Authentication (aka WindowsAuthentication in IIS). Those endpoints require that the HttpClient sends proper user authentication in it's requests.

Right now, we require the user to issue the help command with a parameter, to get information on a particular command. So for instance:

help post

will output

Usage: POST [Options]

Issues a POST request.
Your default editor will be opened with a sample body if no options are provided.

Options:
    --header|-h
    --response
    --response:headers
    --response:body
    --no-formatting|-F
    --streaming|-s
    --no-body
    --file|-f
    --content|-c

A lot of users are probably more used to a syntax where you'd call post help or post --help or post -h or similar. Consider, for example, the git command syntax:

git --help
git branch --help
git branch --help

or the dotnet executable itself may be an even better example since this is a dotnet tool:

dotnet --help
dotnet tool --help
dotnet tool list --help

I think it's totally reasonable to have the help command by itself. But I wonder if we might want to support the other way of calling it as well to make it more discoverable to our users.

cc @jimmylewis @jodavis @shanselman

Inspired by #139, I don't recall seeing any validation around this. It's especially interesting in cases where there is a schema object/array with nested schemas applicable to the properties/items.

For follow-up: test coverage on the HTTP REPL code is very low, it should be improved

I put in a PR #73 with a bug fix for the character duplication mentioned in #15 so that it is usable on linux. However, that whole class (InputManager) and the TTY State and Echo State detection/changing specifically probably needs a whole suite of tests with fakes/mocks for the OS Platform and Process/ProcessStartInfo code. That seemed like too much to block this fix on, so I'm adding this issue to make sure those tests don't get lost.

Currently, there's no way for the pref set command to notify other parts of the system that a preference has changed.

In a lot of cases, that's ok, because the preferences are pulled on an as-needed basis. But some of them may not be.

For example:

1. UseDefaultCredentials/httpClient.useDefaultCredentials is only checked when the HttpClient is first initialized. Changing the setting doesn't take effect until after a restart.
2. HttpClientUserAgent/httpClient.userAgent proposed in #166 is only used to populate the initial set of headers, and is not checked again until after a restart.

Hello guys,

I gave it a try and I really enjoyed it, but I have a little problem with 'POST' (and other verbs that send a body).

My default text editor opens an empty file when it should open with a template based on my swagger.json, right?

I set my default editor with the command - pref set editor.command.default "{{text editor path}}" - and my swager exposes the template for operation as follow:

I dont know if this is a issue or a miss configuration.

Thank you.

The abstract definition is here: https://github.com/aspnet/HttpRepl/blob/master/src/Microsoft.Repl/Commanding/ICommand.cs and it is overridden in the various derived classes, but it is never called.

We should remove it (or, if this is a mistake somehow, correct the mistake).

If you try to do value completion for the set header Content-Type command and you don't have a base address set, the tool crashes.

System.ArgumentNullException
  HResult=0x80004003
  Message=Value cannot be null.
Parameter name: uri
  Source=System.Private.Uri
  StackTrace:
   at System.UriBuilder..ctor(Uri uri)
   at Microsoft.HttpRepl.HttpState.GetEffectivePath(String commandSpecifiedPath) in d:\repos\HttpRepl\src\Microsoft.HttpRepl\HttpState.cs:line 85
   at Microsoft.HttpRepl.HttpState.GetApplicableContentTypes(String method, String path) in d:\repos\HttpRepl\src\Microsoft.HttpRepl\HttpState.cs:line 56
   at Microsoft.HttpRepl.Suggestions.HeaderCompletion.GetValueCompletions(String method, String path, String header, String prefix, HttpState programState) in d:\repos\HttpRepl\src\Microsoft.HttpRepl\Suggestions\HeaderCompletion.cs:line 87
   at Microsoft.HttpRepl.Commands.SetHeaderCommand.Suggest(IShellState shellState, HttpState programState, ICoreParseResult parseResult) in d:\repos\HttpRepl\src\Microsoft.HttpRepl\Commands\SetHeaderCommand.cs:line 96
   at Microsoft.Repl.Commanding.DefaultCommandDispatcher`2.CollectSuggestions(IShellState shellState) in d:\repos\HttpRepl\src\Microsoft.Repl\Commanding\DefaultCommandDispatcher.cs:line 90
   at Microsoft.Repl.Suggestions.SuggestionManager.NextSuggestion(IShellState shellState) in d:\repos\HttpRepl\src\Microsoft.Repl\Suggestions\SuggestionManager.cs:line 39
   at Microsoft.Repl.Input.KeyHandlers.Tab(ConsoleKeyInfo keyInfo, IShellState state, CancellationToken cancellationToken) in d:\repos\HttpRepl\src\Microsoft.Repl\Input\KeyHandlers.cs:line 230
   at Microsoft.Repl.Input.InputManager.<StartAsync>d__19.MoveNext() in d:\repos\HttpRepl\src\Microsoft.Repl\Input\InputManager.cs:line 214
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.HttpRepl.Program.<Start>d__1.MoveNext() in d:\repos\HttpRepl\src\Microsoft.HttpRepl\Program.cs:line 73
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.HttpRepl.Program.<Main>d__0.MoveNext() in d:\repos\HttpRepl\src\Microsoft.HttpRepl\Program.cs:line 24
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.HttpRepl.Program.<Main>(String[] args)

When typing "ls " followed by a tab keystroke crashes the application.

Console dump:

Unhandled exception. System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index')
   at System.Collections.Generic.List`1.get_Item(Int32 index)
   at Microsoft.Repl.Commanding.CommandWithStructuredInputBase`2.Suggest(IShellState shellState, TProgramState programState, TParseResult parseResult) in /_/src/Microsoft.Repl/Commanding/CommandWithStructuredInputBase.cs:line 68
   at Microsoft.Repl.Commanding.DefaultCommandDispatcher`2.CollectSuggestions(IShellState shellState) in /_/src/Microsoft.Repl/Commanding/DefaultCommandDispatcher.cs:line 92
   at Microsoft.Repl.Suggestions.SuggestionManager.NextSuggestion(IShellState shellState) in /_/src/Microsoft.Repl/Suggestions/SuggestionManager.cs:line 39
   at Microsoft.Repl.Input.KeyHandlers.Tab(ConsoleKeyInfo keyInfo, IShellState state, CancellationToken cancellationToken) in /_/src/Microsoft.Repl/Input/KeyHandlers.cs:line 233
   at Microsoft.Repl.Input.InputManager.StartAsync(IShellState state, CancellationToken cancellationToken) in /_/src/Microsoft.Repl/Input/InputManager.cs:line 214
   at Microsoft.HttpRepl.Program.Start(String[] args, IConsoleManager consoleManager) in /_/src/Microsoft.HttpRepl/Program.cs:line 73
   at Microsoft.HttpRepl.Program.Main(String[] args) in /_/src/Microsoft.HttpRepl/Program.cs:line 24
   at Microsoft.HttpRepl.Program.<Main>(String[] args)

It happens when attempting to get suggestion on empty parameter input.

I get this error:

System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.HttpRepl.DirectoryStructureExtensions.TraverseTo(IDirectoryStructure structure, IEnumerable`1 pathParts) in d:\repos\HttpRepl\src\Microsoft.HttpRepl\DirectoryStructureExtensions.cs:line 53
   at Microsoft.HttpRepl.Commands.ChangeDirectoryCommand.ExecuteAsync(IShellState shellState, HttpState programState, DefaultCommandInput`1 commandInput, ICoreParseResult parseResult, CancellationToken cancellationToken) in d:\repos\HttpRepl\src\Microsoft.HttpRepl\Commands\ChangeDirectoryCommand.cs:line 53
   at Microsoft.Repl.Commanding.CommandWithStructuredInputBase`2.ExecuteAsync(IShellState shellState, TProgramState programState, TParseResult parseResult, CancellationToken cancellationToken) in d:\repos\HttpRepl\src\Microsoft.Repl\Commanding\CommandWithStructuredInputBase.cs:line 206
   at Microsoft.Repl.Commanding.DefaultCommandDispatcher`2.ExecuteCommandInternalAsync(IShellState shellState, CancellationToken cancellationToken) in d:\repos\HttpRepl\src\Microsoft.Repl\Commanding\DefaultCommandDispatcher.cs:line 150
   at Microsoft.Repl.Commanding.DefaultCommandDispatcher`2.ExecuteCommandAsync(IShellState shellState, CancellationToken cancellationToken) in d:\repos\HttpRepl\src\Microsoft.Repl\Commanding\DefaultCommandDispatcher.cs:line 113

At first, I thought it was just because I didn't have a base url set. But it seems to happen regardless. On occasion, the stack trace is slightly different (seems to be when I'm at the root?):

System.NullReferenceException: Object reference not set to an instance of an object.
   at Microsoft.HttpRepl.Commands.ChangeDirectoryCommand.ExecuteAsync(IShellState shellState, HttpState programState, DefaultCommandInput`1 commandInput, ICoreParseResult parseResult, CancellationToken cancellationToken) in d:\repos\HttpRepl\src\Microsoft.HttpRepl\Commands\ChangeDirectoryCommand.cs:line 55
   at Microsoft.Repl.Commanding.CommandWithStructuredInputBase`2.ExecuteAsync(IShellState shellState, TProgramState programState, TParseResult parseResult, CancellationToken cancellationToken) in d:\repos\HttpRepl\src\Microsoft.Repl\Commanding\CommandWithStructuredInputBase.cs:line 206
   at Microsoft.Repl.Commanding.DefaultCommandDispatcher`2.ExecuteCommandInternalAsync(IShellState shellState, CancellationToken cancellationToken) in d:\repos\HttpRepl\src\Microsoft.Repl\Commanding\DefaultCommandDispatcher.cs:line 150
   at Microsoft.Repl.Commanding.DefaultCommandDispatcher`2.ExecuteCommandAsync(IShellState shellState, CancellationToken cancellationToken) in d:\repos\HttpRepl\src\Microsoft.Repl\Commanding\DefaultCommandDispatcher.cs:line 113

Right now, the example body always includes "" as the value when the data type is string. But since dates are (always? often?) handled by a type of string and a format of date-time, this ends up providing a default value that will almost never be accepted by the server.

We should detect if the Format property is date-time and provide a better default value (likely just DateTimeOffset.Now.ToString("o") for now, though we could probably make this configurable somehow later.

This is confusing, at least, because you're presented with a file that includes a property that you'd never set in the request body in real life. At worst, it could theoretically cause errors on the server depending on how they handle the json parsing.

We should track and respect the readOnly property of the schema and not write out properties where that property is true.

ui Displays the Swagger UI page, if available, in the default browser

Create an option to pass or set the endpoint for the swagger ui

For example:

C:\>dotnet httprepl
(Disconnected)~ exit

(Disconnected)~
C:\>

I've got a simple node app with a swagger.json like this.
swagger.txt

{ "openapi": "3.0.0", "servers": [ { "url": "/api/v1" } ]...

And while it is correct and valid swagger, it's not automatically usable with httpRepl without manual and non-intuitive base url setting.

set base https://MYSITE/api/v1 set swagger https://MYSITE/swagger.json

The base setting should be implied by the single servers:url and this should work without manual set base or manual set swagger.

Second ask - Would be nice to "Set swagger LOCALFILE" as well. Or even "dotnet watch httprep --swagger LOCALFILE" for iterative development.

cc @tlmii

The ~ character has a specific connotation (home directory) that doesn't match what we're using it for.

Change that character to be a > to better match what most command prompts use by default.

Per an email conversation with @jodavis, include a doc link in the CLI's help text. An aka.ms link will be created once the doc is published. Scott will submit a PR to include the link in the help text.

While I am setting the httprepl swagger using the command :
set swagger http://example.com/api/v2/swagger.json
I get the response :

Process is terminating due to StackOverflowException.

The swagger.json file size is 262 KB.

Hey
I'm trying out httprepl and running into an issue when trying to use it right now.

This is what I'm doing:

dotnet httprepl https://dev.whiteboard.microsoft.com:9062/
https://dev.whiteboard.microsoft.com:9062/~ set swagger /swagger/v1.0/swagger.json

I then get this error: Must specify a swagger document

That is the relative URL to my swagger document and using Fiddler it seems like it's not even trying to make the request.

This is all that I was able to capture in Fiddler and it shows up before I use set swagger:

Hi everyone,

I'm just watching the ASP.NET Community Standup from August 27th and thought that it would be a good fit if this tool would be provided as a Powershell Provider because:

• there would be command history out of the box
• infrastructure for auto completion and other command line actions would be there (e.g. ctrl + space showing all possible commands)
• it would be possible to save the commands as .ps1 scripts and reuse them
• and the best thing it could be integrated with all the available powershell commands (e.g. Where-Object or Select-Object for filtering and reducing the response)

BR, Lukas

Colorization of XML responses isn't supported. As seen in the BaseHttpCommand.FormatJsonAsync method, JSON colorization is supported. I propose that the BaseHttpCommand.FormatXmlAsync method also support colorization in the same way. Along with that support, I'd expect to see colors.xml... settings that the user can customize.

This stems from @jimmylewis's comment on #49 (comment).

There are a lot of cases in the code where we have something similar to:

ICoreParseResult parseResult;
...
if (parseResult.Sections.Count > X && 
    parseResult.Sections[0] == "Y" && 
    parseResult.Sections[1] == "Z")
{
    ...
}

But they have slight variances. "Y" is usually the Name of the command, "Z" (if present) is usually the SubCommand. But X van vary independently of the presence of "Z" and the operator can sometimes be == instead of >.

We should refactor those to make them more consistent (if possible) and more readable.

If not taking advantage of tab completion, it's possible to navigate to an endpoint that doesn't exist. Consider the following web API containing Fruits and People endpoints.

https://localhost:5001/~ ls
.        []
Fruits   [get|post]
People   [get|post]

https://localhost:5001/~ cd pe
/pe    []

When running cd pe in the preceding example, I would've expected:

• Navigation away from the web API root to be prevented.
• An error message such as "The pe endpoint doesn't exist".

/cc @tlmii