# Description
Provides the ability to use http commands as part of a pipeline.
Additionally, this pull requests extends the pipeline metadata to add a
content_type field. The content_type metadata field allows commands such
as `to json` to set the metadata in the pipeline allowing the http
commands to use it when making requests.
This pull request also introduces the ability to directly stream http
requests from streaming pipelines.
One other small change is that Content-Type will always be set if it is
passed in to the http commands, either indirectly or throw the content
type flag. Previously it was not preserved with requests that were not
of type json or form data.
# User-Facing Changes
* `http post`, `http put`, `http patch`, `http delete` can be used as
part of a pipeline
* `to text`, `to json`, `from json` all set the content_type metadata
field and the http commands will utilize them when making requests.
Intends to close#8920
This PR suggests a new flag for the `http` commands, `--redirect-mode`,
which enables users to choose between different redirect handling modes.
The current behaviour of letting ureq silently follow redirects remains
the default, but two new options are introduced here, following the lead
of [JavaScript's `fetch`
API](https://developer.mozilla.org/en-US/docs/Web/API/fetch#redirect):
"manual", where any 3xx response to a request is simply returned as the
command's result, and "error", where any 3xx response causes a network
error like those caused by 4xx and 5xx responses.
This PR is a draft. Tests have not been added or run, the flag is
currently only implemented for the `http get` command, and design tweaks
are likely to be appropriate.
Most notably, it's not obvious to me whether a single flag which can
take one of three values is the nicest solution here.
We might instead consider two binary flags (like
`--no-following-redirects` and `--disallow-redirects`, although I'm bad
at naming things so I need help with that anyway), or completely drop
the "error" option if it's not deemed useful enough. (I personally think
it has some merit, especially since 4xx and 5xx responses are already
treated as errors by default; So this would allow users to treat only
immediate 2xx responses as success)
# User-facing changes
New options for the `http [method]` commands. Behaviour remains
unchanged when the command line flag introduced here is not used.
# Description
this commit adds the handling of Value::List when BodyType is Json
it also adds the corresponding test (trying to send a list)
Fixes#10319
# User-Facing Changes
Added the ability to send a json list in the POST message
# Tests + Formatting
- [x] `cargo fmt --all -- --check` to check standard code formatting
(`cargo fmt --all` applies these changes)
- [x] `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used`
to check that you're using the standard code style
- [x] `cargo test --workspace` to check that all tests pass (on Windows
make sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- [x] `cargo run -- -c "use std testing; testing run-tests --path
crates/nu-std"` to run the tests for the standard library
Also ran `nc -l -p 8080` in other terminal and `http post -fe -t
application/json http://localhost:8080 [{ field: true }]` I see the
following appear in the output of nc:
```
POST / HTTP/1.1
Host: localhost:8080
User-Agent: nushell
Accept: */*
Content-Type: application/json
accept-encoding: gzip
Content-Length: 16
[{"field":true}]%
```
This PR fixes a bug introduced in
https://github.com/nushell/nushell/pull/8571.
We were accidentally converting a `Result<Value, ShellError>` to JSON
instead of converting a `Value`. The upshot was that we were sending
JSON like `{"Ok":{"foo":"bar"}}` instead of `{"foo":"bar"}`.
This was an easy bug to miss, because `ureq::send_json()` accepts any
`impl serde::Serialize`. I've added a test to prevent regression.
# Description
_(Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.)_
This pull request removes `Reqwest` and replaces it with `Ureq` to
remove some of our dependencies, giving us faster compile times as well
as smaller binaries. `Ureq` does not have an async runtime included so
we do not need build heavy dependencies such as `Tokio`. From older
tests I had the number of build units be reduced from `430 -> 392`.
The default of `Ureq` uses `Rustls` but it has been configured to
instead use `native_tls` which should work exactly the same as the `tls`
works now.
I removed `content-length` from the http commands as after refactoring i
did not see a reason to have it available, correct me if this is
something we should preserve.
In the medium, to long term, we should maybe consider changing to
`rustls` to have the same `tls` on all platforms.
# User-Facing Changes
_(List of all changes that impact the user experience here. This helps
us keep track of breaking changes.)_
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
# Description
Following the comment from @fdncred:
https://github.com/nushell/nushell/pull/8144#issuecomment-1442514338. I
added some unit tests for HTTP commands. The tests are not exhaustive,
but at least, this is a first good step IMO.
# User-Facing Changes
None.
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
