-
Notifications
You must be signed in to change notification settings - Fork 82
Conversation
How about aspnet/StaticFiles#84 |
What about it? |
@BrennanConroy Is it supposed to be fixed here too? |
|
Yes, we shouldn't conflate the 2 issues. This might be slightly related but it's not the same bug. |
@BrennanConroy Where is the test for this fix? |
Sorry, I don't think I was quite clear in aspnet/StaticFiles#84 that My opinion (and the fix I have waiting to create a pull request for [if you guys think what I have is okay]), is that the static file middleware see's the invalid characters in the request and skips on it, leaving it up to the next middleware in the pipeline... most likely ending up in a 404 returned to the client, not a 500. |
{ | ||
return null; | ||
// path contains a colon (":") that is not part of a volume identifier (for example, "c:\"). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should avoid first chance exceptions like these in cases where we know it will throw.
I think this and aspnet/StaticFiles#84 are the same class of failure and should be addressed in similar ways. E.g. something like this: https://github.com/brentnewbury/StaticFiles/commit/11e02d1a513f41a8dc704027dd6a50e25f64054e#diff-565cc1cae6ec9b8df50ec6fb281418b4R120 rather than a try/catch. |
That looks good, but we'll still need to handle having a colon in the string |
@BrennanConroy Revert this. |
You need to go through and make sure every call to a Path API with external data (e.g. a request path, but not the constructor) is guarded. Also, don't use try/catch, check for invalid characters explicitly. |
+1 |
#137
@Tratcher