Allow configurable accepted HTTP status codes for webhook protocol
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 52/100
Direzione di ricerca
Inizia individuando la gestione delle risposte di consegna del webhook e le relative definizioni di configurazione nel repository Go. Traccia il punto in cui HTTP 200 viene attualmente trattato come successo, quindi aggiungi la copertura per il comportamento predefinito e per una risposta 202 consentita; il lavoro è completato quando i codici di stato accettati sono configurabili, mantenendo al contempo i valori predefiniti limitati a 200.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The webhook protocol currently treats only HTTP 200 (http.StatusOK) as a successful response. Any other status code (including other 2xx codes such as 202) is treated as an error.
Please add support for an allowlist of accepted status codes (e.g. 200, 202) so webhook integrations can treat other 2xx codes as success.
Some webhook endpoints legitimately respond with status codes other than 200 (for example 202 Accepted when the payload is queued for async processing). Today these are handled as failures even though the request succeeded from the sender’s perspective.
For instance, this would be helpful a Zipkin-related input package being added in elastic/integrations:
And zipkin receiver returns a 202 code when sending JSONs to its endpoint (related code).
Could it be added a new configuration option to define which HTTP status codes should be considered successful for webhook delivery (as allowed list)? The default value for this allowed list should be 200 to keep the same behavior as it is now.
- Lingua principale
- Go
- Stelle
- 12
- Fork
- 17
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di elastic/stream
-
bug Team:Security-Service Integrations
Difficoltà 2/5 1-3 ore Idoneità per principianti 48/100
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
-
enhancement
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 55/100
Tutte le issue di elastic/stream
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
I maintainer di solito rispondono entro 1 giorno
-
bug raised-by:verifier
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
medici-finance/assay#5697 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
sonatype-nexus-community/terraform-provider-sonatypeiq#101 ·
I maintainer di solito rispondono entro 1 giorno
-
area: metrics area: tracing contribfest enhancement good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
open-telemetry/opentelemetry-ebpf-instrumentation#4188 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
blinklabs-io/dingo#6074 ·
I maintainer di solito rispondono entro 1 giorno