Hi Jason,
Relative paths work, but they have to be relative to the root of the domain. That is to say, if you install wordpress at domain.com/blog/ then all of your destination urls will have to be either full URLs or start with /blog/. If WordPress is installed in the root you should have no problems.
Thanks. I think that answers my question. Another fork of that question…
If I do full path redirects on the dev server will they create any conflicts? Or will they snap into place and work when the dev site becomes the live site?
example:
old: http://site.com/oldpathblabla.asp
new: http://site.com/newpath/
(meanwhile the dev server still has a path like http://devsite.com until DNS is repointed)
Really just wondering if I should take the risk and wait to do the 301 redirects when the site is actually live and risk being crawled by Google and losing some clicks while updating links or if they can be done in advance.
I think I’m following you. If you use full path destinations on the dev site, the pages won’t work until you go live. That is to say, if you specify that /oldpathblabla.asp should redirect to http://site.com/newpath/, it will always go to the full path. so if you went to http://devsite.com/oldpathblabla.asp it would redirect you to the full path that you specified (http://site.com/newpath/) and not automatically figure out that you wanted http://devsite.com/newpath/
Hope that answers your second question.
It should be noted here that relative paths, while they work in most web browsers, are invalid according to spec. Therefore, they aren’t guaranteed to work in every application.
http://tools.ietf.org/html/rfc2616#section-14.30
http://en.wikipedia.org/wiki/HTTP_location
Scott, a good solution would be, if a path started with ‘/’, automatically include the current domain in the Location
header.