2009/2/17 Paul M Foster <paulf@xxxxxxxxxxxxxxxxx>: > On Mon, Feb 16, 2009 at 08:34:22PM +0000, Stuart wrote: > > <snip> > >> This is your problem, you're not understanding where the paths are >> being resolved. Apache has absolutely no involvement in resolving >> relative paths in your HTML files to absolute URLs. The browser does >> this. All you need to do is use absolute URLs and everything will work >> fine. By absolute, in case you don't know, I mean starting with a / >> and being "from" the document root in the web server. > > FWIW, I've been doing computers since before the CP/M days > (pre-pre-DOS), so I do know the difference between absolute and relative > paths. FWIW I've been "doing" computers for a long time also, and am well aware of CP/M. Based on what you said it didn't appear that you did know the difference, but I apologise for the mistake. I'm sure if you look at the URLs being requested by the browser it should be pretty clear that it's simply adding the paths you have in your HTML to the end of the existing URL. The fact that you didn't appear to have seen that informed my assumption. > I'm a little doubtful about the browser specifying things like the URLs > for links within a HTML page. However, this would explain why there are > separate entries for image fetches in the Apache logs, occurring after > the main page has been requested. Do you have some reference for this? > I'd like to read more about the server-client interaction in depth. I couldn't find any references so I wrote a quick overview of what the process is. Note that this is over-simplified but should get the basic process across. * Browser connects to the HTTP server on www.google.com and requests / * Server resolves / to a resource, commonly an HTML file, PHP script or whatever, processes it if necessary and sends the output back to the browser. * Browser receives the HTML content, parses it, builds a list of referenced URLs (images, scripts, stylesheets, etc) * Browser normalises each referenced URL according to a fairly simple set of rules... If the URL is not already in the form scheme://... If the URL does not start with a / // The URL is relative to the current location If current_url ends with / URL = current_url + URL Else URL = dirname(current_url) + '/' + URL Fi Else // The URL is absolute on the current domain // current_domain is everything needed to hit the same web server, so scheme://[[username]:password@]domain.com URL = current_domain + URL Fi Else // URL is already absolute, including the scheme, domain name, etc Fi * Browser then (usually) fires off a couple of threads to request the additional URLs, renders the page and executes any scripts it contains. The server has absolutely no involvement in resolving referenced URLs to complete URLs - this is all done by the browser. HTTP is stateless to the extreme, meaning that each request gets a single resource, even if they're done through the same connection. Hope that makes it clearer. >> For example, if you have a tag like <a href="arse.php">arse</a> and >> arse.php is in the same directory as index.php you need to change it >> to <a href="/arse.php">arse</a>. >> >> Another example... if you have <a href="somedir/crack.php">crack</a> >> where crack.php is in the subdirectory somedir beneath where index.php >> is you need to change the tag to <a >> href="/somedir/crack.php">crack</a>. >> >> You need to apply this to all URLs in your code, including >> stylesheets, images and javascript references. This should not be a >> difficult concept to grasp, so maybe I'm not explaining it right. If >> so please explain what you understand by what I'm saying and I can >> alter it to be more helpful. > > Here's the issue I have with this: normally I build pages on the fly > with PHP. However, on this particular project, my wife is building the > pages in Dreamweaver. And, as I mentioned before, while in development, > the pages reside on an internal server, like this: > > http://pokey/example.com > > That is, pokey is an internal Debian machine where all our client sites > reside as backups in the /var/www directory. So as far as pokey is > concerned, the pages are at: > > /var/www/example.com > > but we see it as: > > http://pokey/example.com > > Dreamweaver has a very brain dead way of handling templates, resultant > pages, and the internal page links. And while my wife is very savvy, > her Windows-weenie-Dreamweaver way of handling links is to click on a > button which opens a dialog box, in which she finds the image, and > clicks "Okay". > > This is all fine while the pages are on the development server. (Well, > not really, since Dreamweaver regularly hacks up image links in > non-intuitive ways.) But when they get uploaded to the production server > on the internet, all those absolute links have to change from: > > http://pokey/example.com/graphics/myportrait.gif > > or > > /example.com/graphics/myportrait.gif > > to > > http://example.com/graphics/myportrait.gif > > or > > /graphics/myportrait.gif > > Moreover, I'm not even sure she can specify the links absolutely when > doing her "Click and Search" routine. She'd probably have to manually > type them in, unless there's some setting in Dreamweaver I don't know > about. > > In any case, changing absolute links in development pages to absolute > links in production pages would involve a heap of (dangerous) global > search-and-replace magic. > > So specifying absolute links might be a bit much. I'm not happy with the > way DW handles this stuff, but I have to strike a balance between my > vim-handcoding-command-line method and my wife's > click-and-drag-gotta-be-GUI method. We've covered this in the other thread. I can't speak for DW since I've only ever used it as a text editor, and even then only when forced, but I would be surprised if you couldn't tell it to generate absolute URLs. Something I do know is that you can set it up to automatically deploy to a separate virtual host on your development server, but based on the other thread you've already made a decision on how to solve your problem. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
