I've been asked to create a few different folders with the same name but with different capitalizations. The idea behind this is to allow for errors in capitalization when someone types in a specific url. They want to do something like this:
www.website.com/youtube
www.website.com/Youtube
www.website.com/youTube
www.website.com/YouTube
I believe this is bad practice for many reasons, mainly that it seems confusing and unnecessary and any updates to these pages will have to be done 4 times over. I've also noticed that VSCode won't let me create these directories from within the editor and my computer, a windows machine, won't let me do it from within the file manager either.
I've seen that this can create a problem with git as it won't recognize the files as separate files regardless of capitalization.
So really my questions are:
1.) Is there a way to do this?
2.) If so, is it a bad practice?
3.) If it's a bad practice, why?
I'd like to do it for them if possible, but not if there are some unforeseen consequences that I'm not aware of. Any insight would be appreciated.
Thanks in advance.
edit: Just to be clear, we already have www.website.com/youtube but a few users have reported that their browser autocorrects the 'youtube' section of the url to have the Y or the T capitalized. From what I see now, to accomplish this we must do something on the server side, of which my knowledge is limited. All I know for sure is that it is a Linux server.
To start with, the sane solution would be redirect those routes to the proper one, which is not an uncommon task. I don't know what your infrastructure looks like to the ease of doing so is unknown.
1.) Is there a way to do this?
Assuming that your server is Linux/BSD/Using anything but a Windows NTFS filesystem, yes. You can have one folder as source of truth and create symlinks. Or again, you could make the routes case-insensitive on whatever server you're using.
2.) If so, is it a bad practice?
Cloning the same information and making the same updates repeatedly is terrible practice. Making symlinks on the server is slightly less bad but still pretty bad practice, as that's cluttering up your directory tree with unnecessary nonsense.
3.) If it's a bad practice, why?
The idea isn't bad practice, you can make case-insensitive routes on most modern server configurations. The provided suggestions are pretty bad. But without knowing what your stack looks like, we can't provide much more information on how to do it.
Related
I've tried looking it up and am now coming back to here to see if I can get my question answered. Why should I make it so that others cannot view my indexes? Is there a security reason for this?
I'm just beginning in web development....so I definitely could use any help/info that you all can provide.
It's often considered a security best practice to hide directory listings. You may accidentally upload files to your docroot that you don't want to share to the world. Without knowing the URL, nobody would be able to access them. While this is a very thin layer of security, it can be helpful.
There are certainly times when you may want a directory listing, such as download directories. It's up to you to decide what is useful to you. If you don't need it, don't use it. If you do, use it.
Before anyone has a chance: Yes, i know it's a bad idea. Please, don't give me a lecture on how i should use a web service instead. Thanks.
So, how could this be done?
I found this bit http://www.karlkraft.com/index.php/2010/09/17/mysql-for-iphone-and-osx/ and thought it might do the trick. I got a bunch of ARC error messages, cleaned those out and got this error at runtime:
Detected an attempt to call a symbol in system libraries that is not
present on the iPhone: pthread_cond_init$UNIX2003 called from function
my_thread_init in image oms.
Do i need to use something like ODBC/C?
I know that the solution might be a lengthy one, that's fine. Would be great if someone could at least point me in the right direction.
EDIT:
Since people are keen to know the reason for opting not to use a web service, here it is:
If you're creating an in-house app, the added security of a web service is next to nothing. Working directly with the DB means i need to maintain less code. Plus i don't need to create hacky PHP scripts to get things done.
FINAL CONCLUSION:
I wanted to leave a message for people who're about to do the same thing: Don't :)
Essentially your options are hacky server side scripts or Oracle proprietary mysql client you built yourself (and thus a hacky solution as well). Your choice but i'd strongly advice against it.
This might be the sort of thing that you are looking for:
mysql for iphone and osx
I found it on this iphonedevsdk thread access mysql remote database iphone
Personally I would be only doing this if you really really wanted to.
If you wanted a canned solution, I also found this: Flipper
Or to do it yourself: Build MySql client library for iPhone/iPad
Its not really that hard to find a number of solutions
I needed the same thing (I understand your lecture-pain ;) ) so I wrote this: https://github.com/ciaranj/MySqueakQl it doesn't link to the mysql client libraries so no GPL issues, but it is a very minimal ... very 'fresh' i.e. untested implementation ... just my 2c.
I faced the same problem as you did. I searched and find this.
In http://www.acapela-for-iphone.com/ios-4-2-gm-small-problem-with-simulator
Jean-Michel Reghem Says:
"It seems that Apple changes (again) something into the simulator (as in iOS 4.0)."
Also some people in that page say that this problem didn't show up in device, you can try.
The author has updated his code, and it worked.
Here is the link: http://www.karlkraft.com/index.php/2011/06/07/mysql-for-iphone-and-osx-version-2-0/
I'm wondering if there are any best practices for organizing files on the filesystem for a site that centers around users uploading files. (Not a hosting site like Imageshack, more like addons.mozilla.org)
Or am I over-analyzing this and should put everything in one folder?
I tend to think about user uploads as just another kind of user data, and so it all goes into a database. Obviously, make sure the database you are going to use for this is a good choice for that, for example, a SQL database isn't necessarily right.
If it makes sense, I try to use a url pattern that makes sense in the context of the usage pattern of the site, for example:
example.com/username/users_file.jpg
If there's just no obvious way to do that, and I have to use a surrogate key, I just live with it:
example.com/files/abc123
example.com/files/abc123/
example.com/files/abc123/users_file.jpg
All three are the same file. in particular, the abc123 is all that the app needs to look up the file, the extra bit at the end is there so that browsers get a good hint at what the file should be named when it's saved to disk.
Doing it this way means that no matter what the original file is named, it always is unique to the user. Even if the user wishes to upload 100 files with the same name, all are unique.
First (and probably obviously), put the users' files in some dedicated place so they don't risk overwriting other stuff.
Second, if you expect lots of files then you may want to have subfolders. The easiest way to do that is to use the first letter of their filename as the folder.
So if I were to upload "smile.jpg", you could store it there: s/smile.jpg
If you're super popular and still have too many files, you can use more letters. And if you expect to have tons of users and you have tons of servers, you can imagine splitting the work by saving on s.example.com/upload/s/smile.jpg (but really if you have tons of servers then you probably already have a transparent way of sharing storage and load).
I need to decide on naming conventions for a new website.
I can use mod_rewrite at will.
My favourite solution would be to work with no file extension at all.
www.exampledomain.com/language/pagename
this would lead to "pagename" being treated as a directory. I would have to take that into account when using relative links.
Are there any other pitfalls I need to be aware of when doing this?
Is this legal, or are resources supposed to have a "name.prefix" structure?
Do you know of any clients that can't deal with this and start looking for /index.htm or .html?
Can you think of any SEO problems to be expected?
Unless you have a very good reason to add an extension, drop it.
are resources supposed to have a "name.prefix" structure?
Not that I know of. Normally not. Resources are just a concept. A custom resource format may have that extension requirement, the other would not. It will depend.
As for SEO, the short a link is, the better. It will increase relative weight of keywords. An extension would make links longer by 4 characters or more.
Do you know of any clients that can't deal with this and start looking for /index.htm or .html?
A problem may arise if you decide to support multiple entry points.
www.exampledomain.com
www.exampledomain.com/index.html
www.exampledomain.com//index.htm
www.exampledomain.com/index
These are all different urls to search engines. Some people will be linking to you with the shortest name, the others will use the other version. Then ultimately there will be different inbound links pointing to your site start page which will essentially be the same. Search engines will detect it and see it as content duplication. Consequently, your page rank will be divided between several url versions. Finally, all except one will likely be dropped out of their index entirely. To deal with this situation, decide for one "true" url and let others perform 301 redirect (moved permanently) to the "correct" url.
Dropping extensions actually has the significant benefit of not tying you to a specific language. If your URLs are http://example.com/page.php and you switch to another language, you'll either lose the existing URLs (bad!) or have to fake the PHP extension (clunky).
On my website, I have several html files I do not link off the main portal page. Without other people linking to them, is it possible for Jimmy Evil Hacker to find them?
If anyone accesses the pages with advanced options turned on on their Google toolbar, then the address will be sent to Google. This is the only reason I have can figure out why some pages I have are on Google.
So, the answer is yes. Ensure you have a robots.txt or even .htaccess or something.
Hidden pages are REALLY hard to find.
First, be absolutely sure that your web server does not return any default index pages ever. Use the following everywhere in your configuration and .htaccess files. There's probably something similar for IIS.
Options -Indexes
Second, make sure the file name isn't a dictionary word -- the odds of guessing a non-dictionary word fall to astronomically small. Non-zero, there's a theoretical possibility that someone, somewhere might patiently guess every possible file name until they find yours. [I hate these theoretical attacks. Yes, they exist. No, they'll never happen in your lifetime, unless you've given someone a reason to search for your hidden content.]
Your talking about security through obscurity (google it) and it's never a good idea to rely on it.
Yes, it is.
It's unlikely they will be found, but still a possibility.
The term "security through obscurity" comes to mind