Multipart Form Data "RoutingContext::fileUploads"
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Bắt đầu bằng cách kiểm tra việc xử lý multipart xung quanh RoutingContext::fileUploads, body của RoutingContext, body handler và map dữ liệu đã được xác thực. Xem xét hoặc thêm các test bao phủ việc upload file, tên file không rỗng của Content-Disposition, streaming ra đĩa và các giới hạn kích thước upload của body handler; hoàn thành khi các giá trị và hành vi này có thể được sử dụng mà không tiêu tốn quá nhiều bộ nhớ.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Describe the feature
Multipart form data has changed quite a bit with this new strategy. I'm not sure if this is the actual plan going forward, but we're losing what I think is pretty crucial functionality from what I can tell. One of which being that files used to be streamed to disk and then available to be streamed somewhere else from the file. The other is the filename of the file uploaded in the multipart form data, which comes from the content disposition header.
Maybe this already exists through some other form, but I don't see any tests in this repo that upload file, set a nonempty content disposition or use the body handler for limiting file upload size.
Use cases
Streaming files means that there's less risk of out of memory exceptions. Also, the content disposition header is standard and being unable to access its value through some means is weird.
These are probably just not supported yet, but I find it pretty weird how many breaking changes are being introduced. RoutingContext::fileUploads and the RoutingContext body just aren't used anymore from what I can tell. The validated body has to be pulled from the data map now in the context instead.
Contribution
Who should implement this feature ? are you volunteering for implementing this feature or
do you know that is able and willing implement this feature ?
- Ngôn ngữ chính
- Java
- Star
- 15
- Fork
- 19
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của eclipse-vertx/vertx-openapi
-
bug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
eclipse-vertx/vertx-openapi#137 · 5 bình luận ·
-
Add OpenAPI 3.2 supportĐang mởenhancement help wanted
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
eclipse-vertx/vertx-openapi#136 · 1 bình luận ·
-
enhancement
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 38/100
eclipse-vertx/vertx-openapi#122 · 4 bình luận ·
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 48/100
eclipse-vertx/vertx-openapi#117 · 6 bình luận ·
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
eclipse-vertx/vertx-openapi#93 · 1 bình luận ·
Tất cả issue của eclipse-vertx/vertx-openapi
Issue tương tự
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
AllTheMods/AllTheModium#238 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
apache/stormcrawler#2264 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
commons-app/apps-android-commons#7115 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
objectionary/lints#1596 ·
Maintainer thường phản hồi trong vòng 2 ngày