Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#997 0 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
冷清
技术栈
java, scala
领域
backend-api-design

调研方向

阅读 http/src/main/scala/org/apache/pekko/http/scaladsl/coding/，重点关注 Coder、Compressor、StreamDecoder 和 Coders.DefaultCoders，然后检查 Java coding API。定义两个 DSLs 中自定义 coder 所支持的扩展点和协商行为。完成标准是达成一致的 API 设计，并提供用于注册和使用的实现测试与文档。

由索引模型根据 Issue 内容生成。

描述

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)

主要语言
Scala
星标
196
派生
56
平均合并
1 天 18 小时
30 天内合并 PR
43

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

apache/pekko-http 的其他 Issue

查看 apache/pekko-http 的全部 Issue

相似的 Issue

更多 Scala Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。