buglwIP - A Lightweight TCP/IP stack - Bugs: bug #56290, HTTPD 404/400/501 URI detection...


You are not allowed to post comments on this tracker with your current authentication level.

bug #56290: HTTPD 404/400/501 URI detection causes wrong headers to be sent

Submitted by:  Josh <inojosh>
Submitted on:  Wed 08 May 2019 04:53:01 PM UTC  
Category:  apps Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  Simon Goldschmidt <goldsimon>
Open/Closed:  Closed Planned Release:  None
lwIP version:  Other

Thu 30 Jan 2020 08:23:54 PM UTC, comment #4: 

Fixed by checking for filenames to start with (e.g.) "400." for both httpd and makefsdata. This should be a good compromise between wrong positives and keeping old fs trees working.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Tue 14 May 2019 07:34:17 PM UTC, comment #3: 

Yeah, well, I meant checking for "/400." as the start. But of course you can come up with "/400.log", so yes, a dedicated check for a defined filename would be better, like you suggested.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Mon 13 May 2019 05:56:03 PM UTC, comment #2: 


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 expense...)

What do you think?

Josh <inojosh>
Fri 10 May 2019 06:56:27 PM UTC, comment #1: 

A defined filename isn't an ideal solution as it could be html or shtml. But maybe a defined starting path? So that both /404.html and /404.shtml match but /log404.html doesn't.

Could you provide a patch?

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Wed 08 May 2019 04:53:01 PM UTC, original submission:  

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.

Josh <inojosh>


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by inojosh (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-01-30 goldsimon StatusNone => Fixed
        Assigned toNone => goldsimon
        Open/ClosedOpen => Closed

    Back to the top

    Powered by Savane 3.5