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

Response header schema checks: remaining slices

Aperta
  • Qualcosa non va?
#1,117 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
go
Ambito
api

Direzione di ricerca

Start from slice 1 (#1116, oasdiff v1.26.0) to see how type/format/nullability checks were added for a response header's schema, then study the request-parameter checkers named as the closest template for walking nested properties and constraints. For part 2, find where ContentDiff is produced for headers and how request/response bodies already classify media types as strongly typed. Done means the new rule ids are registered and covered by tests for both the schema-property walk and the content path, symmetric across request and response headers.

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

Descrizione

Follow-up to #1094, which is closed now that slice 1 shipped in #1116 (oasdiff v1.26.0). Slice 1 added type, format, and nullability checks on a response header's schema. This issue tracks the rest.

1. Full property machinery for header schemas

Slice 1 only covers the header schema's own type/format/nullability. It does not yet cover:

  • Constraints: pattern, minLength/maxLength, minimum/maximum, enum narrowing/widening, etc., the same checks response body properties already get.
  • Nested properties: walking a header schema that is itself an object/array, mirroring how ResponsePropertyTypeChangedCheck walks body properties.

This is the "walk header schemas through the same property machinery bodies use" part of #1094, and it is many new rule ids, so it is worth doing in further slices. The request-parameter checkers (which already walk parameter properties) are the closest template.

2. Content-serialized headers

A header can use content instead of schema (e.g. content: application/json) for complex serialization. That value is genuinely JSON, so it would be strongly typed, and it surfaces as a ContentDiff on the header, not a SchemaDiff. The current checks only walk SchemaDiff (the simple text serialization, correctly non-strongly-typed), so content-serialized headers are not checked at all.

This is a symmetric gap: request headers do not cover the content path either today, so both sides can be closed together, classifying the value strongly-typed via its media type the same way request and response bodies already are.

Context

The classification basis for slice 1: a header value is text on the wire, so the schema path is non-strongly-typed (a plain string to integer swap is backward compatible; dropping a parsed format or widening the returned type is breaking). The content path above is the exception that would be strongly typed.

Lingua principale
Go
Stelle
1.4k
Fork
109
Merge medio
12h 11m
PR unite (30g)
35

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 oasdiff/oasdiff

Tutte le issue di oasdiff/oasdiff

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.