As an example, the Rails parameterize method would create a string like so:
"hello-there-joe-smith" == "Hello There Joe.Smith".parameterize
For legacy reasons, a project I am working on requires uppercase letters as well as periods to be available in a particular URL parameter.
Why would this ever be a problem?
Clarification
The url type I'm talking about is what is used instead of an id, commonly knows as a slug.
Would a Rails app with the following url come to any issues: http://example.com/Smith.Joe?
This will be a problem both in terms of SEO and browser caching (and hence performance,)
Search engines are case sensitive, so same URL in different case will be taken as two URLs.
Browser like IE's caching is case sensitive, so eg. if you try to access your page as MYPAGE.aspx and at some place in code, you write it as mypage.aspx then IE will treat them as two different pages and instead of getting it from cahce, it will get it from server.
Dashes should be fine but underscores should be avoided : http://www.mattcutts.com/blog/dashes-vs-underscores/
Related
I have seen big company such as facebook, google or yahoo etc use a mix of mod write and query string,
facebook:
https://www.facebook.com/zxzxzx
https://www.facebook.com/events/upcoming?action_history=null
google:
https://www.google.com.hk/search?q=asddvdfv
https://plus.google.com/u/0/xxx
what is the best practice when dealing with url?
mod rewrite with URL is used for making smart readable URL in browser, so search engines can read them correctly. Also its meaningful URL so user can also read URL with meaning. So most of directory listing or informative pages are rewritten with mod rewrite.
When there is searching activity or too many parameters in the query string such as param1=..., param2=..., or when dynamic parameters are used in URL its not beneficial to write meaningful URL and in that case mix URL should be used
if in listing pages where you used meaningful URL (with mod rewrite) and you additionally using some dynamic parameters like paging parameters, its not necessary to rewrite them also, but you can in this situation pass those parameters as query sting like you see in second Facebook link
Is it bad practice to make a page that has a web address like these:
http://example.com/-products-and-services.php
http://example.com/-contact-us.php
http://example.com/--books.php
http://example.com/--translation.php
http://example.com/--illustration.php
http://example.com/-$-special-feature.php
http://example.com/-$-vip-area.php
Will google or apache have problems with these (- $) characters?
I am doing this because I makes it easier for me to view and categorise pages while still letting me add keywords to the file names.
Thanks
You can use alphanumerics, and the special characters "$-_.+!*'()," in url.
But it may not be very helpful with seo, search engine indexing etc.
You can read what google says here,
https://support.google.com/webmasters/answer/76329?hl=en
Trying to add a sharing function to my site, but GPlus seems to have trouble sharing url's with spaces in them.
Even escaped they dont seem to work.
eg;
https://plus.google.com/share?url=http://www.google.com/%23test%20test
It only seems to recognize upto before the %20.
Any ideas? Is this a bug? Am I doing something wrong?
The site is rather ajaxy, and in the history tokens would be a pain to need to use non-standard escaping of characters just for google plus.
I don't think that this is a bug with Google+ but rather its likely intentional because those URLs would need to be double URL encoded because one URL is sharing a second URL, thus your shared URL should be http%3A%2F%2Fwww.google.com%2F%2523test%2Btest
This won't work to create a preview in the share snippet but the URL is correct when it is shared.
All said, you shouldn't use spaces in your URLs because they are considered unsafe, see RFC 1738. You should change your app's URL structure.
Let's say that I have a web app that responds to URLs in the format /entities/{entityKey}. In my access logs, I find people visiting both /entities/KEY1 which is how app URLs are generated, as well as the lower case version of /entities/key1. Currently key1 will throw a 404 not found error due to route requirements.
My question is, would you:
Use URL re-writing to re-write key to uppercase.
Create 302 redirects from lowercase to uppercase?
Have the application convert to uppercase and handle requests in a case-insensitive fashion
Most users these days expect URLs to be case-insensitive. I would have the app silently handle the conversion in the background. I don't see it being worth the extra request time to issue a redirect.
If SEO is a concern, then you can use the rel="canonical" meta tag to let google/other search engines know which URL you want to appear in search results.
I have a RESTFul WCF service with a url likes this
groups/{groupName}/members
which returns a list of users this works fine for normal groupNames. But when I use a groupName with a special char (like #) nothing is returned
ex.
when the url
groups/c#/members
is called from the client it only returns null.
I put a break point in the service code but the service's method is not even executed.(Break point never gets hit)
Also I tried using the url encode to encode c# as c%23 but the result is still the same. I tried this with built in web server of VS 2010 and IIS 7 but the result is still the same.
And I am using .NET 4.0
Any help will be really appreciated
In a url the hash indicates the end of the url and what follows it is a reference to a specific portion on the page, so the url /groups/c#/members is interpreted as the url /groups/c (and then the browser tries to take you to the href on the page named "/members".
Basically you should never allow # as a character in your dynamic url's. There's a reason people generate permalinks with only alphanumeric characters separated by dashes, and it's not just for readability/SEO. Some characters just plain aren't allowed. You should look at having a permalink field in your application so groups might have a name of c# which you display on page, but also a url friendly version of the name like c-sharp.