Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

The cookbook example "Accessing HTTP Response Metadata While Streaming" doesn't stream

Đang mở
#2,232 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
58/100
Loại issue
Tài liệu
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
shell
Lĩnh vực
documentation

Hướng nghiên cứu

Bắt đầu với ví dụ trong cookbook có tiêu đề "Accessing HTTP Response Metadata While Streaming" và tái hiện ví dụ đó với https://example.com. Xác định một dạng streaming rõ ràng hơn các cách workaround được minh họa bằng $in hoặc biểu thức điều kiện; được xem là hoàn thành khi status và content type được in ra trong khi HTTP body vẫn khả dụng cho lệnh lines tiếp theo.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

The example in question is:

http get --allow-errors https://api.example.com/events.jsonl
| metadata access {|meta|
    print $"Status: ($meta.http_response.status)"
    print $"Content-Type: ($meta.http_response.headers | where name == content-type | get value.0)"

    if $meta.http_response.status != 200 {
        error make {msg: $"Failed with status ($meta.http_response.status)"}
    } else { }
  }
| lines
| each { from json }
| where event_type == "error"

This won't work because the input to the closure is fed to the first statement, which is print $"Status: ...", while the closure output is taken from else {}. If the http response status is 200, the closure will always output nothing because the input for the closure was consumed by print. We can't test this because api.example.com is a fake subdomain, so let's modify the example to use example.com and not assume the output is json:

http get --allow-errors https://example.com
| metadata access {|meta|
    print $"Status: ($meta.http_response.status)"
    print $"Content-Type: ($meta.http_response.headers | where name == content-type | get value.0)"

    if $meta.http_response.status != 200 {
        error make {msg: $"Failed with status ($meta.http_response.status)"}
    } else { }
  }
| lines

If you run this, you will see that the status and content type are printed, but the http body is not returned from the closure.

One solution is to use the $in variable to collect the input and return it from the else statement:

http get --allow-errors https://example.com
| metadata access {|meta|
    let input = $in
    print $"Status: ($meta.http_response.status)"
    print $"Content-Type: ($meta.http_response.headers | where name == content-type | get value.0)"

    if $meta.http_response.status != 200 {
        error make {msg: $"Failed with status ($meta.http_response.status)"}
    } else { $input }
  }
| lines

This does return the http body from the closure, but the example is called "Accessing HTTP Response Metadata While Streaming", and $in collects the input, so it's no longer a stream.

If we want to make this work while streaming, we can make the if statement into the only top level statement of the closure by moving the print statements into its conditional expression:

http get --allow-errors https://example.com
| metadata access {|meta|
    if (
        print $"Status: ($meta.http_response.status)";
        print $"Content-Type: ($meta.http_response.headers | where name == content-type | get value.0)";

        $meta.http_response.status != 200
    ) {
        error make {msg: $"Failed with status ($meta.http_response.status)"}
    } else {  }
  }
| lines

When run, this streams the http body after printing the status and content-type. However, it is pretty hacky. If we were to put this in the cookbook, it would need an accompanying explanation as to how sticking statements in the conditional expression prevents them from eating the closure input. Perhaps someone with more nushell experience than me can come up with a cleaner way to write this?

Ngôn ngữ chính
TypeScript
Star
260
Fork
563
Merge trung bình
4 giờ 36 phút
Pull request đã merge (30 ngày)
16

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của nushell/nushell.github.io

Tất cả issue của nushell/nushell.github.io

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.