Forum Moderators: phranque

Message Too Old, No Replies

mod rewrite: how can I stop 'add path info postfix' affecting js src=

Attempt to have 'nice' URLs is preventing <script> files loading

         

anoble

11:54 pm on Feb 18, 2011 (gmt 0)

10+ Year Member



I'm sure this is easy, but I am new to mod_rewrite and am getting lost in the various posts.

1. I want users to have nice-looking URLs:
mysite.com/niceName1/niceName2 to rewrite to mysite.com/index.php?one=niceName1&two=niceName2

2. I do this in .htaccess as follows:

RewriteEngine on
RewriteRule ^([^./]*)/([^./]*)$ /index.php?one=$1&two=$2 [L]

3. But in index.php I have <script src="assets/myfile.js"> which results in a 404 error since this URL becomes /niceName1/assets/myfile.js

4. The mod_rewrite log file shows that 'add path info postfix' is adding the $1 pattern from step2.

How can I prevent this?

Thank you so much anyone who can help a mod_rewrite beginner.

jdMorgan

12:36 am on Feb 19, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Your rule needs a tweak for robustness:

RewriteRule ^([^./]+)/([^./]+)$ /index.php?one=$1&two=$2 [L]

(do not allow blank values for 'one' or 'two') but it would not have rewritten your myfile.js requests even without this change: The two subpatterns explicitly reject values for "one" and "two" that contain any periods and/or slashes, and therefore no rewrite will take place for myfile.js because it contains a period.

I suspect that the real problem is that you've used page-relative links and they're broken because they cause the browser to request myfile.js as example.com/one/two/assets/myfile.js

Change all of your included-object links to use either server-relative or canonical URLs such as
<script src="/assets/myfile.js"> or <script src="http://example.com/assets/myfile.js"> instead of page-relative links.

The most common problem by far encountered with "virtual-directory-based" rewriting is the use of page-relative links, because it is the client (browser or 'bot) that resolves relative links to canonical URLs based on the URL of the page that it finds those links on -- i.e. the page URL in the browser's address bar.

Jim

anoble

1:18 am on Feb 19, 2011 (gmt 0)

10+ Year Member



Jim - you have solved that brilliantly. As you suggest, I have used server-relative URLs and all is working fine.

I have used page-relative links in the past as they seemed easier with virtual directories under IIS. Apache's virtual directories seems much cleaner (today was my first - very long- day with Apache) so I will switch all links to server-relative.

I cannot tell you how impressed I am with your response. Thank you so very much.

Can you recommend any webmaster 'bibles' (books, links, anything) so that I do not waste people's time with this sort of question, and one day hopefully be able to contribute some knowledge back?

Thank you so much.
Best wishes,
Arthur

jdMorgan

4:00 pm on Feb 19, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



The existence of this forum shows that there's no comprehensive 'bible' out there. There are, however, some very good books available in the technical section of most larger bookstores, in the book section of most computer-product retail stores, and of course, on-line. I prefer the retail stores simply because it's easier to pick through the books and find one (or a few) that best meet your needs as to style, organization, and content for each subject.

You may continue to use page-relative links, except for links on pages whose URLs are rewritten and differ in directory-path from the actual server filepaths. Many Webmasters prefer page-relative links because they are the shortest, and also because they allow the site to be 'previewed' on the development computer without having to install a server on that development workstation. However, use of page-relative links on pages whose URLs are rewritten almost always causes this problem, which is why I said it is most common.

The 'big surprise' in this is that many Webmasters don't have a clear understanding that it is the client that resolves any kind of relative links to the canonical URL that it requires in order to make an HTTP request for an included object or another page. For some reason, that point isn't obvious to many (or maybe even most) Webmasters...

Anyway, don't be too 'impressed.' Whenever we answer a thread about "How do I rewrite requests for URL-path /a/b/c to filepath /index.php?p1=a&p2=b&p3=c ?", it's almost guaranteed that the very next post will be "Hey, that works, but now all of my image/CSS/JavaScript includes are broken." About the only time we don't see that is when the site is brand new and is being developed from the bottom up, and these included objects and links to them don't yet exist. :)

Jim