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

Allow plugin support for custom compression/decompression (e.g. zstd)

Đang mở
  • Có gì không ổn?
#997 0 bình luận 1 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ó
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
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
java, scala
Lĩnh vực
backend-api-design

Hướng nghiên cứu

Đọc http/src/main/scala/org/apache/pekko/http/scaladsl/coding/, tập trung vào Coder, Compressor, StreamDecoder và Coders.DefaultCoders, sau đó kiểm tra Java coding API. Xác định các điểm mở rộng được hỗ trợ và hành vi thương lượng cho các coder tùy chỉnh trong cả hai DSLs. Công việc được xem là hoàn tất khi có thiết kế API đã được thống nhất, cùng với các bài kiểm thử triển khai và tài liệu về việc đăng ký và sử dụng.

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

Mô tả

enhancement

Feature request: Plug-in support for custom compression (e.g., zstd) in Pekko HTTP coding subsystem

Context

Currently, Pekko HTTP provides built-in support for gzip (and deflate) compression via the Coder abstraction in org.apache.pekko.http.scaladsl.coding. This is used via encodeResponse, decodeRequest, and related directives, and the negotiation machinery is well-established. There is frequent interest (e.g., for modern formats like zstd) in supporting custom content encoding algorithms. Users may want to plug in their own encoders/decoders without modifying Pekko HTTP core code.

There is #860 which is about adding built-in support for zstd but it might be worth considering allowing the addition of custom compression/decompression so users can add support themselves.

Analysis

After reviewing the codebase (scaladsl/coding), here's what enables and what currently blocks custom compressions:

What works:
  • Coder is a marker trait (trait Coder extends Encoder with Decoder). Users can implement it today to support new encodings, e.g., zstd.
  • HttpEncoding.custom(...) allows defining new encoding tokens, such as zstd.
  • Directives (encodeResponseWith, decodeRequestWith) accept arbitrary Encoder/Decoders, so user-provided implementations can already be injected explicitly per-route.
Current barriers:
  1. Compressor and StreamDecoder are Internal/Deprecated:
    • Compressor (needed for encoding) and StreamDecoder (for decoding) are @InternalApi and @deprecated. Implementing Encoder/Decoder needs usage of these, but they're not public API and may change or disappear, so user-providers can't rely on them.
  2. Java API is closed:
    • The Java-side equivalent (org.apache.pekko.http.javadsl.coding.Coder) is a closed enum—Java users cannot add custom encoders at all.
  3. Default coders are fixed:
    • Coders.DefaultCoders is always [Gzip, Deflate, NoCoding]. There is no mechanism for registering a custom coder with the negotiation machinery globally. So, while you can use your custom coder per-route with the With directives, it won't be automatically used with default directives.
Example: How it could work (after stabilising APIs)
object ZstdCoder extends Coder with StreamDecoder {
  val encoding: HttpEncoding = HttpEncoding.custom("zstd")
  def messageFilter = Encoder.DefaultFilter
  private[this] def newCompressor = new ZstdCompressor() // if Compressor is public
  def newDecompressorStage(maxBytesPerChunk: Int) = () => new ZstdDecompressorStage(maxBytesPerChunk)
}
// Usage:
encodeResponseWith(ZstdCoder, Coders.Gzip, Coders.Deflate, Coders.NoCoding) { ... }
decodeRequestWith(ZstdCoder, Coders.Gzip, Coders.Deflate) { ... }
Proposed Enhancements
  1. Promote Compressor and StreamDecoder to Public API:
    • Remove @InternalApi and @deprecated from these types
    • Alternatively, provide a new public API for plugging in custom encoder/decoder flows
  2. Open up Java API for Custom Coders:
    • Replace or supplement the hardcoded Coder enum with an interface/factory-based mechanism in the Java DSL
  3. Make DefaultCoders Configurable or Injectable:
    • Allow applications to register additional coders (e.g., via ActorSystem config or a registration method) for use by the default directives/negotiator
  4. (Optional) Add zstd as a built-in or contrib module:
    • To showcase extensibility and provide instant value
  5. (Docs) Add a guide for implementing and registering custom coders
Impact
  • This would unlock modern and/or domain-specific compression for Pekko HTTP users
  • Immediate benefit for projects that need zstd or other algorithms (Brotli, LZ4, etc.)
  • Makes Pekko HTTP encoding/decoding as extensible as its routing layers

If maintainers agree, I'm happy to help with API stabilisation PRs or further design discussion!

Origin: https://github.com/apache/pekko-http (discussion/analysis by pjfanning)

Ngôn ngữ chính
Scala
Star
196
Fork
56
Merge trung bình
1 ngày 18 giờ
Pull request đã merge (30 ngày)
43

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 apache/pekko-http

Tất cả issue của apache/pekko-http

Issue tương tự

Thêm issue về Scala

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.