Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Add protocol for handling Request & Response

Aperta
  • Qualcosa non va?
#372 7 commenti 3 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
clojure
Ambito
api, backend-api-design

Direzione di ricerca

Start by reviewing the current ring-spec and the request/response handling in the Jetty adapter, Aleph, and Immutant mentioned in the issue. Compare those interfaces with the proposed RingRequest protocol and the Undertow wrapper context. Done would require an agreed protocol design, compatible implementations for existing server types, and a documented plan for the breaking change.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Many modern Java Web Server (Netty, Undertow, Vert.x) have their own abstractions for Requests and Responses. Current ring-spec states that requests and responses as map-like structures. While this is awesome in abstraction-wise (and the killer feature of Ring), performance-wise it can be bad as data needs to be copied into maps. Copying can be eager (like with the jetty-adapter) for all requests or lazy (like Aleph & Immutant) / on demand, but still things like accessing a single header value forced all headers to be read copied and keys lowercased.

Abstracting the request and response as protocols would allow best of both worlds. A protocol like:

(defprotocol RingRequest
  (get-server-port [this])
  (get-server-name [this])
  (get-remote-addr [this])
  (get-uri [this])
  (get-query-string [this])
  (get-scheme [this])
  (get-request-method [this])
  (get-protocol [this])
  (get-headers [this])
  (get-header [this header])
  (get-body [this])
  (get-context [this]))

could be implemented for maps so that they do the normal lookup, but the Aleph-style zero-copy-request (map-like) classes could implement those directly. (get-header request "Content-Type") would use the already parsed information without any copying.

This would allow low-level libraries to be programmed against effective protocols while keeping everything compatible with maps.

Currently working on a new lightweight and zero-fat new wrapper for Undertow and using a custom request protocol (like the one above) with it, but would not like to tie our other libraries to a server-specific protocols.

All the current web servers having their own request & response (map-like) types would need to conform to the new protocols, so would be a breaking change.

Lingua principale
Clojure
Stelle
3.9k
Fork
528
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ring-clojure/ring

Tutte le issue di ring-clojure/ring

Issue simili

Altre issue su Clojure

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.