Yep, we intentionally avoid invalid inputs to keep things simple. Might change this in the future by adding additional “optional” stages that check edge cases more.
Our reasoning here is that if you’re primary aim is to learn, it’s okay to not be too bothered with edge-cases. In the HTTP server challenge for example, even if these cases weren’t handled you’d still get to learn how the HTTP protocol works.
And secondly, edge cases are hard to cover exhaustively via tests. As an example, there might be an implementation that checks p.includes("/files") so we’d need another test to check that an input with /files in a different position is handled. And there also might be implementations that check p.includes?("file") so we’d need a counter-example to check that too. Just seems super hard to reliably test all edge cases, so we choose to avoid it altogether for now 
I think one thing we might end up doing in this space is to have better validation on code examples we highlight. Currently, we’re only filtering by “Relevance” when looking for code examples to highlight (more on this here: "Concise" code examples - #2 by rohitpaulk). We could add additional filters that check whether an implementation is “proper”.