Summary: HTTPD 404/400/501 URI detection causes wrong headers
to be sent
Project: lwIP - A Lightweight TCP/IP stack
Submitted by: inojosh
Submitted on: Wed 08 May 2019 04:53:01 PM UTC
Severity: 3 - Normal
Item Group: Faulty Behaviour
Assigned to: None
Discussion Lock: Any
Planned Release: None
lwIP version: Other
In HTTPD, get_http_headers checks for the existence of "404", "400" or "501"
anywhere in the URI and sets the status header based on what is found.
This causes bad headers to be sent when a genuinely good file happens to have
those anywhere in the URI.
For example: I use custom FS to load files that are dynamic (they are coming
from elsewhere - just important to note they are not statically compiled
webpages, and their filenames are not under my control).
For example: the file "bad7fd3aade94aad64c82a07c74002aa.jpg" causes the
HTTP_HDR_BAD_REQUEST header to be sent. This hex string is just an example,
you could have anything: "data_log_number_501.txt" would send
Instead of making assumptions, maybe it should #define specific filenames for
the 404/400/501 cases, in httpd_opts.h? Just a suggestion.
For now I will just remove these checks altogether, but I think this behavior
should be changed in the long run, in the official release.
[bug #56290] HTTPD 404/400/501 URI detection causes wrong headers to be sent
Follow-up Comment #2, bug #56290 (project lwip):
What about "4007fd3aade94aad64c82a07c74002aa.jpg"? This is just as possible as
the previous example "bad7fd3aade94aad64c82a07c74002aa.jpg". Each has 400 in
the file name, one just happens to have it at the beginning. I think any fix
should eliminate absolutely any possibility of a file other than the actual
true error file serving up the wrong status headers.
If a defined starting path is used, it seems like it would be necessary to
also check the files explicitly, instead of "URI starts with /404". That is,
the defined path + .html, .htm, or .shtml. This would fix it fully (at some