misconfigured `servlet-root` leads to confusing state
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 38/100
Línea de trabajo
Reproduce la configuración usando la raíz de archivos "htdocs" y la raíz de servlets ".", luego sigue el bucle de filesystem-map.rkt alrededor de la línea indicada y el Racket issue 5488 enlazado. Determina dónde se oculta la configuración incorrecta y considera cómo el servidor web puede proporcionar una respuesta clara en lugar de la página genérica de archivo no encontrado.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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! 😅
- Lenguaje dominante
- Racket
- Estrellas
- 100
- Forks
- 48
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de racket/web-server
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 70/100
racket/web-server#46 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
racket/web-server#140 ·
-
`make-dir-store` is not atomicAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 45/100
racket/web-server#135 ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
racket/web-server#131 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 45/100
racket/web-server#127 ·
Todos los issues de racket/web-server
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
bmander/geomsolver#118 ·
Los mantenedores suelen responder en 1 día
-
bug needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
bug priority:high
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
api bug claude
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
diegosouzapw/OmniRoute#15764 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
btclib-org/btclib-wallet#301 ·
Los mantenedores suelen responder en 1 día