unRAID OS Version: 6.0.0

 

Description: often enHTTP will return a 200 OK message for pages that dont exist. On first glance it seems to stem from case sensitivity.

 

How to reproduce: http://server/nothere.asp = 404 http://server/Nothere.asp = 200

 

Expected results: In all cases when a page is not found a 404 must be returned.

 

Actual results: 200 OK message and unexpected page content

 

Other information: None

It's because if the 'path' component of the URL starts with a capital letter it's assumed to be a "page" reference.  emhttp performs a translation:

 

p = path component of URL

if (first character of p is upper case) then

  GET template.php?path=p

else

  GET p

 

When php processes 'template.php' it uses the 'path' query variable to determine which page to render inside the 'content' division of the webGui page.  If 'page' does not exist, then you just get a header and footer returned with 200 status.

 

This is simple and fast, and not sure it's worth fixing/changing.

I humbly suggest it is very much worth fixing.

 

RFC requires 404s and madness lies within not following RFC standards for something as fundamental as HTTP. Its the foundation of everything and user to devs to clients all assume and require it works and weird things can happen when they dont.

I humbly suggest it is very much worth fixing.

 

RFC requires 404s and madness lies within not following RFC standards for something as fundamental as HTTP. Its the foundation of everything and user to devs to clients all assume and require it works and weird things can happen when they dont.

 

Understood, but we're not talking about a "normal" website, it's a client application that uses a browser.  Besides, it does return valid data, it just has null content in one of the divisions.  But sure, I get your point.  If it were to be "fixed" though, I don't think returning 404 is the correct response.  Instead the page body should just have a message: "unknown webGui page" or something like that.

It should definitely be a 404 that is the spec the browsers expect and are coded to understand.

 

If it was the other way around and Chrome decided to not honour the HTTP spec we would be up in arms.

 

I honestly think there is no wiggle room here. I cannot think of any sentence that starts with "The unRAID webgui is not RFC compliant..." that ends well.

 

Edit: sorry for coming on strong but this is a pet hate of mine. From the security side I see this all the time and it causes me endless amounts of grief with audit fails, accreditation fails and bot escalations. Its amazingly common to ignore this or have some clever spin that doesnt cover all edge cases.