lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #56290] HTTPD 404/400/501 URI detection causes wrong h


From: Josh
Subject: [lwip-devel] [bug #56290] HTTPD 404/400/501 URI detection causes wrong headers to be sent
Date: Wed, 8 May 2019 12:53:03 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.131 Safari/537.36

URL:
  <https://savannah.nongnu.org/bugs/?56290>

                 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
                Category: apps
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: Other

    _______________________________________________________

Details:

lwIP version 2.1.2 (not available in dropdown)

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
HTTP_HDR_NOT_IMPL.

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.




    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?56290>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]