OPTIONS responses ignore the actual routes
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 30/100
Direzione di ricerca
The OPTIONS handling lives in MaxLib.WebServer/Services/HttpHeaderSpecialAction.cs, reached from ParseRequest; start there, then read the WebService interface and the Builder that derives routes from [Path] and [Method] to find where a path-acceptance probe would hook in. RoutingDryRun is explicitly ruled out as too heavy. Done means a handled path answers 204 with an Allow header listing the union of supported methods, otherwise 404 — but the interface design is still open.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
HttpHeaderSpecialAction answers every OPTIONS request in ParseRequest
(HttpHeaderSpecialAction.cs):
- It answers for every path, including paths no service handles.
- It always lists
GET POST HEAD OPTIONS TRACE. Some of these may not be supported for the path, and other supported methods are missing.
RoutingDryRun cannot be used for this: it needs a complete request (method, headers, …), it only answers "accepted or not", and it collects analytics that are too costly per request.
Proposal
Add a lightweight path probe that follows the normal execution flow, but checks only the path:
- Ask each service whether it accepts the path. Ignore method, arguments, headers and body.
- Return whether any service accepts the path, plus the union of the methods those services support.
HttpHeaderSpecialAction then answers:
- path accepted:
204 No Contentwith anAllowheader listing the union of methods - path not accepted:
404 Not Found
Open points
- How a service reports path acceptance and supported methods, for example an optional interface on
WebService. The Builder can derive both from[Path]and[Method]. - How to represent "any method" (a Builder route without
[Method]). - Custom services that cannot answer the probe: whether to treat them as "accepts the path, any method", or to skip them.
- Lingua principale
- C#
- Stelle
- 0
- Fork
- 2
- Merge medio
- 1g 9h
- PR unite (30g)
- 4
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
- 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 Garados007/MaxLib.WebServer
-
documentation good first issue severity:low
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
-
bug severity:low
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
-
bug security severity:medium
Difficoltà 2/5 1-3 ore Idoneità per principianti 80/100
-
bug severity:low
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
bug severity:low
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
Tutte le issue di Garados007/MaxLib.WebServer
Issue simili
-
type/automation type/tech-debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
area-integrations
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
:watch: Not Triaged dotnet-framework/svc install-deployment/subsvc
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
[Tool] DirectBenchApertahas-image has-readme needs-attention new-tool repo-verified
Difficoltà 1/5 1-3 ore Idoneità per principianti 62/100
shanselman/TinyToolTown#844 · 2 commenti ·
I maintainer di solito rispondono entro 3 giorni
-
:watch: Not Triaged Pri3
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno