misconfigured `servlet-root` leads to confusing state
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 38/100
Direzione di ricerca
Riproduci la configurazione usando la radice dei file "htdocs" e la radice dei servlet ".", quindi traccia il ciclo di filesystem-map.rkt intorno alla riga segnalata e il Racket issue 5488 collegato. Determina dove la configurazione errata viene ignorata e valuta come il server web possa fornire una risposta chiara invece della pagina generica di file non trovato.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I am trying to move an old use of the web server (from version 3.99 approx) to the new web server library and it has a configuration table that gets used via configuration-table->sexpr. In that configuration, file-root is set to "htdocs" and servlet-root is set to ".", but in the actual file system, the servlets are in the directory that contains "htdocs". That is, the correct configuration should have been setting servlet-root to ".." (or moving the servlets I suppose).
The problem, however, is that this configuration did not result an a sensible error message or even any error message. Instead, what happens is that an attempt to run the servlets results in a web page that says “The file you were looking for was not found on this server.”. This seems to be happening because there are some error-swallowing handlers that are pretty misleading. The real troublesome one seems to be the one in this loop that causes the web server to iterate through all of the path components of the url and eventually terminate due to this error.
I'm not sure of the best approach to dealing with this, but some thought towards a better response from the webserver to a similar kind of misconfiguration would be much appreciated. It doesn't have to be anything particularly sophisticated but tracing through what happened in the code to understand my misconfiguration was not a nice experience! 😅
- Lingua principale
- Racket
- Stelle
- 100
- Fork
- 48
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
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 racket/web-server
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 70/100
racket/web-server#46 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
racket/web-server#140 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 45/100
racket/web-server#135 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
racket/web-server#131 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 45/100
racket/web-server#127 ·
Tutte le issue di racket/web-server
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
FuRongJun-1999/dsh-memory#65 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
hexlet-codebattle/codebattle#2361 ·
-
`FakeBackendV2.run` fails with `NoiseError` on circuits with delays on qubits where T2 > 2·T1Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
Qiskit/qiskit-aer#2466 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno