Blog for The Well Designed URLs Initiative

I’ve long believed email provides one of the better justifications for good URL design. Having a well designed URL structure inspires a user to have faith in a site’s URL integrity making it more likely then will email a URL to their friends. What’s more, a good URL gives hints to what can be found making it more likely for an email recipients to visit the link. And a readable URL provides something to “google” when the emailed URL is mangled or simply mistyped by the sender.

But it simply hadn’t occurred to me just how important URL design can be for marketing emails until today when I read a post today by Mark Brownlow of Email Marketing Reports. Mark’s post, entitled Forget email design, what about URL design? discusses the immediately obvious benefits of URL design in email marketing and lists several reasons why email marketers should pay particular attention to their URLs.

As Mark effectively states, well designed URLs can (elaborations mine):

• Reinforce a brand message (when a good domain and/or logic URL path is used),
• Help orientate the reader (within the website’s structure, and/or regarding the offer),
• Provide text clues to the destination page’s content and value,
• Indicate important content relationships (via the URL path’s heirarchy and/or between multiple emailed URLs), and
• Remain relevant and recognisable over a long period of time (assuming the email marketer has a process in place to manager their site’s URL architecture.)

In addition Mark also gives a few examples that clearly make the case for good URL design in email marketing. He effectively asks which of these two URLs send a stronger message to the prospect?

1. http://www.brandk.com/land.php?123456
2. http://www.brandk.com/rings/coupon/

I think the preferrable one is obvious, don’t you?

Mark also suggests providing your prospect with their own custom call-to-action URL in marketing emails such as:

http://www.brandk.com/rings/coupon/justformark/

I too believe that providing customers with their own personal well designed URL can be an incredibly powerful marketing and SEO strategy. However, I’m not so sure it will work well for unknown prospects.

Well done Mark. Nice to have another URLian on the bandwagon.  :-)

I’ve been monitoring the ietf-http-wg mailing list and have noticed there is renewed actively around revising RFC 2616, the HTTP/1.1 specification. This renewed activity got me thinking it was time to discuss the need for HTTP Request Forwarding.

I’ll start by saying it is possible that Request Forwarding is already part of the HTTP spec and that I just overlooked it. Lord knows I’ve read enough W3C and IETF specs lately to raze a small forest if printed, so I could easily have missed that part as I read bleary-eyed through the specs. But I’ve asked the question privately of a few people that should know and they all said that HTTP does not support request forwarding; one of them pointed out that that is why VOIP needed SIP.

If the term “HTTP Request Forwarding” isn’t obvious from context, let me give a use-case to illustrate:

USE-CASE: Retaining control of URL Interfaces when outsourcing image hosting

1. http://example.com
2. http://image-servers-r-us.net
3. http://example.com/index.html
4. http://example.com/images/splash.png
5. http://image-servers-r-us.net/example.com/splash.png

Assume client “A”, server “B” mapped to [1] and server “C” mapped to [2] (servers “B” and “C” are different computers with different IP addresses probably at different locations.) For this use case client “A” requests the HTML file at [3] which includes an <img> tag pointing to a graphic at [4].

The request from client “A” for the .html file at [3] goes to server “B” and the response is returne to client “A.” After parsing [3] client “A” realizes it also needs to download the image at [4] and requests the .png file from server “B” at [1].

However, server “B” knows that the .png file [3] is actually located on server “C” at [5] so it forwards the request to server “C” at [2]. Server “C” responds by returning the .png file directly back to client “A” and client “A” is none the wiser; i.e. client “A” still thinks that the image was returned by [4].

In addition, if client “A” is a browser and the user inspects the properties of the image, the user would find the URL to be [4], not [5]. No where in the response given to the client would there be information that the image came from [5] instead of [4] except that the IP address differs from the server that requested it. It is possible that a header could contain the forwarding information, but the client would not need to act on it except potentially for debugging.

There are several other use-cases as well, such as making it possible to fully virtualize a domain authority’s URL interface. However, the use-case of outsourcing images or any large static content illustrates a benefit that I believe should be obvious to most people. And for those that are interested, especially if you are involved in updating the spec, I could detail other use-cases if people are interested.

Now it is possible there are security implications with this that I have not considered. If so, I would hope that we could at least explore potential ways to mitigate those issues as opposed to immediately dismissing HTTP Request Forwarding out of hand.

In summary, adding a Request Forwarding functionality to HTTP would allow servers to maintain control of their URL interfaces while still being able to distribute loads and services to appropriate servers. Having such a feature could improve consistency in URL design and make it easier for website owners to restructure their websites without the level of broken links seen on the web today.

Interestingly, on Tuesday Scott Hanselman blogged about just this problem from a slightly different perspective; I present Scott’s post for your consideration.

“Wikipedia’s URL spaces are highly elegant; I suspect it’s one of the reason’s Wikipdedia is successful”

-Bill de hOra on “Wikipedia’s Highly Elegant URLs“

“…one should take an hour or so and really think about their website’s ‘public face.’”

-Scott Hanselman on “A Website’s Public Face“

“A URL is like a big “YOU ARE HERE” sign for each page of your site. It should allow people to get a sense of where they are in your site, even if they decide not to use that information for navigation.”

-Keith Devins on URL Design

This is quiz #2 of our ongoing URLQuiz series.

In this quiz, there are 26 pairs of URLs (A..Z) and for each pair the questions is: “Which of these two URLs are equivlent?” i.e. which return the same resource when dereferenced, and “Which can be cached as the same URL?”

You should answer ‘Yes‘, ‘No‘, or ‘Maybe‘ where ‘Maybe‘ means ‘It might return the same resource but should not be cached according to the specs.’

To answer, leave a comment and ideally explain your reasoning for each. Feel free to group answers based on your reasoning and/or the answer given (Yes, No, and Maybe.) Print it out and take the quiz with pencil and paper if you serious about getting it right, and feel free to use a computer or browser or whatever to test your results before answering. Good luck!

About the TLD .foo[1]

Clarification (2007-March-02): Some people have stated that the server could possibly return the same resource for any two given URLs so they felt the answer could never be ‘No.’ I definitely see their point, for example http://mysite.foo/bar and http://mysite.foo/bazz could possibly return the same thing but nobody would ever reasonably expect them to do so on their on. So let me clarify to say that I meant a quiz taker to select ‘No‘ in the case where where the resource returned would definitely not be the same thing unless the developer or server admin explicity programmed or configured them to do so. On the other hand ‘Maybe‘ would be used in the case where someone might reasonably expect the two URLs to return the same resource even though the RFC 3986 would define the two URLs as being different such as in [footnote 2], or when it depends on the O/S of the server as in [footnote 3]. Regarding fragments, the question is “In a transaction between a client and a server, is the cache allowed to view them as the same?” Regarding which can be cached I was looking for what are appropriate per the spec, not necessarily whether any particular software in the cloud (i.e. routers, proxies, browsers, etc.) actually does cache but instead “Would it be allowed to cache?”

Questions

1. The ‘www’ domain
   1. http://mysite.foo/
   2. http://www.mysite.foo/
2. Letter casing in path
   1. http://mysite.foo/Index.htm
   2. http://mysite.foo/index.htm
3. Letter casing in domain
   1. http://MySite.foo/index.htm
   2. http://mysite.foo/index.htm
4. Index.htm vs. Default.aspx
   1. http://mysite.foo/Index.htm
   2. http://mysite.foo/Default.aspx
5. Trailing slash on domain
   1. http://mysite.foo
   2. http://mysite.foo/
6. Trailing slash on path
   1. http://mysite.foo/path
   2. http://mysite.foo/path/
7. Empty question mark
   1. http://mysite.foo/
   2. http://mysite.foo/?
8. Empty parameter
   1. http://mysite.foo/?
   2. http://mysite.foo/?param=
9. Port 80
   1. http://mysite.foo/
   2. http://mysite.foo:80/
10. Port 443
    1. http://mysite.foo/
    2. http://mysite.foo:443/
11. Https vs. Port 443
    1. https://mysite.foo/
    2. http://mysite.foo:443/
12. Ftp vs. Http
    1. ftp://mysite.foo/
    2. http://mysite.foo/
13. Letter casing in parameter name
    1. http://mysite.foo/?param=bar
    2. http://mysite.foo/?Param=bar
14. Letter casing in parameter value
    1. http://mysite.foo/?param=bar
    2. http://mysite.foo/?param=Bar
15. Hash vs. no hash
    1. http://mysite.foo
    2. http://mysite.foo#
16. Hash vs. Fragment
    1. http://mysite.foo#frag
    2. http://mysite.foo#
17. Fragment vs. no Fragment
    1. http://mysite.foo#frag
    2. http://mysite.foo
18. Plus vs. Space in path
    1. http://mysite.foo/url+design
    2. http://mysite.foo/url design
19. Space vs. Encoded Space in path
    1. http://mysite.foo/url design
    2. http://mysite.foo/url%20design
20. Plus vs. Encoded Plus in path
    1. http://mysite.foo/url+design
    2. http://mysite.foo/url%2Bdesign
21. Slash vs. Encoded Slash in path
    1. http://mysite.foo/top/second
    2. http://mysite.foo/top%2Fsecond
22. Ampersand vs. Encoded Ampersand in path
    1. http://mysite.foo/abc&xyz
    2. http://mysite.foo/abc%26xyz
23. Ampersand vs. Encoded Ampersand in parameter value
    1. http://mysite.foo/?q=abc&xyz
    2. http://mysite.foo/?q=abc%26xyz
24. Equals vs. Encoded Equals in path
    1. http://mysite.foo/abc=xyz/
    2. http://mysite.foo/abc%3Dyxz/
25. Equals vs. Encoded Equals in parameter value
    1. http://mysite.foo/?q=abc=xyz
    2. http://mysite.foo/?q=abc%3Dyxz
26. Parameter order
    1. http://mysite.foo/?abc=123&xyz=987
    2. http://mysite.foo/?xyz=987&abc=123

P.S. Don’t stress if you can’t answer them all. It took me months to uncover all these nuances, and if I were taking this quiz I doubt I could get them right all in one sitting.

FootNotes

1. I’m using the non-existent top-level domain “.foo” to avoid giving any link-love to arbitrary example sites that don’t deserve it! For the purpose of the quiz, just assume that “.foo” is a functioning top level domain.
2. Question A.
3. Question B.