Closed gerneio closed 4 years ago
Thank you. Web servers are typically case sensitive. This is also cross platform so it will often run on case sensitive filesystems, meaning only the prefixes would be case insensitive. Blob providers are also case sensitive.
In light of how much of the path will always be case sensitive, I'm not sure this is a good change. What are your thoughts?
If that is indeed the case (I'm only really familiar with a windows hosted environment), then I would suggest a configurable option where we can specify the case sensitivity level.
Hector G. Bas III
On Tue, Jul 28, 2020, 5:07 PM Lilith River notifications@github.com wrote:
Thank you. Web servers are typically case sensitive. This is also cross platform so it will often run on case sensitive filesystems, meaning only the prefixes would be case insensitive. Blob providers are also case sensitive.
In light of how much of the path will always be case sensitive, I'm not sure this is a good change. What are your thoughts?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/imazen/imageflow-dotnet-server/pull/12#issuecomment-665308401, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADKNR4SSEIOSZMG2TE543JTR55D2BANCNFSM4PK6NN6Q .
I made some changes to the PathMapping class and added a property for "IgnoreCase", which is "false" by default, therefore providing the default behavior. This will propagate all the way up to the ImageflowMiddlewareOptions.MapPath method.
@lilith I wanted to also point out that you are not always using case sensitive path matching.
For example in the ImageJobInfo.ProcessRewritesAndAuthorization method.
So decision is up to you for what route to go, but either will work.
Rewrites and authorization rules are case-insensitive, true. I think it makes sense to have authorization rules catch case variations for safety. And I think rewrites should probably be configurable instead of their current default.
I'm considering if this might be better as a global setting. Blob provider mappings are currently collected as lists of strings, so we would need significant refactoring to make case-sensitivity configurable across the board. Blob providers are also case-sensitive for filenames and we can't do much about that other than offer to lowercase all incoming blob provider paths.
I need to mull this over a bit more before I decide on what to do. I really want consistent and predictable behavior across all file providers of Imageflow.NET Server.
Ya, I was thinking the same thing, but knew it would be a much more involved project, haha!
Don't think it over for TOO long! :) We'll definitely need case insensitivity in play prior to us ever putting this into production. We can never guarantee the case of any incoming image URL. And can you imagine the frustration of trying to debug why an image isn't rendering or being received properly only to discover that you should have used a capital "V". Additionally, oftentimes we have third party vendors that are reaching out to our servers for the requested images, and we can't control if they pre-process the URL for whatever reason.
I've implemented granular control over case sensitivity for S3, Azure, RemoteReader, and path prefixes. Check it out in the latest release.
Seems to be working well, thanks for getting that taken care of so quickly!
Noticed when using "MapPath" that the path seems to be case sensitive, when it shouldn't be:
Calls like "https://localhost:44315/Vehicle/image.jpg?width=101" won't work because of the capital "V" in the virtual path. Changing it to a lowercase "v" will then produce the image. Should work either way or at least be configurable.
Note that this code change is untested, so you may need to verify it.