Re: [PHP] Apache odd behavior
Paul M Foster wrote: On Mon, Feb 16, 2009 at 08:34:22PM +, Stuart wrote: 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. 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. The client requests the web page. The server sends the web page. After the client gets the web page it then parses the web page and requests any inline elements, such as images, style sheets, iframes, etc. - which is why you can have images in different servers etc. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache odd behavior
I'm submitting a url like this: http://mysite.com/index.php/alfa/bravo/charlie/delta The index.php calls has code to decode the url segments (alfa/bravo/charlie/delta). It determines that the controller is alfa, the method is bravo, and converts charlie and delta to $_GET['charlie'] = 'delta'. It verifies that the controller and method exist, and calls the controller and method. This works fine. The right controller gets called and the right method, and the GET parameter looks like it should. The method sets some variables and then calls a render() function to render the page, which is in the doc root of the site. The page does get rendered, but without the stylesheet, and none of the graphics show up. Why? Because, according to the logs, Apache appears to be looking for the images and everything else in the directory index.php/alfa/bravo/charlie/delta, which of course doesn't exist. No, I don't have an .htaccess file with RewriteEngine on. Apache figures out that index.php is the file to look for in the original URL, but can't figure out that everything else is relative to that file, not the entire URL. This method is in use in at least one other MVC framework. What am I doing wrong? hi Paul, to make your css and images work, do something like this img src=/image.jpg / and link href=/style.css type=text/css rel=stylesheet media=screen / the slash at the start tells the browser to start looking from the root. good luck. Virgil http://www.jampmark.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache odd behavior
2009/2/17 Paul M Foster pa...@quillandmouse.com: On Mon, Feb 16, 2009 at 08:34:22PM +, 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]:passw...@]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.phparse/a and arse.php is in the same directory as index.php you need to change it to a href=/arse.phparse/a. Another example... if you have a href=somedir/crack.phpcrack/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.phpcrack/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
Re: [PHP] Apache odd behavior
On Tue, Feb 17, 2009 at 12:27:58PM +, Stuart wrote: 2009/2/17 Paul M Foster pa...@quillandmouse.com: On Mon, Feb 16, 2009 at 08:34:22PM +, 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. Well, the only way I know this is to look at the Apache logs. I was getting a lot of 3xx and 4xx errors (which don't show up directly in the browser), and looking at the requests, it appears that the browser is indeed dictating the place to find images, etc., based on the odd URL. 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]:passw...@]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. Thanks for the summary. snip 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. I leave Dreamweaver issues to my wife. She maintains she can manually type in the link URLs, but that's really not a good ongoing paradigm. Now, if Dreamweaver had a config setting that said, Make all URLs absolute, I'd say that's the best resolution. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache odd behavior
2009/2/17 Paul M Foster pa...@quillandmouse.com: Well, the only way I know this is to look at the Apache logs. I was getting a lot of 3xx and 4xx errors (which don't show up directly in the browser), and looking at the requests, it appears that the browser is indeed dictating the place to find images, etc., based on the odd URL. If you don't already have it get Firefox. Once you have that google for the livehttpheaders extension. Using that you can see exactly what the browser is asking the server for, including all headers. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache odd behavior
2009/2/16 Paul M Foster pa...@quillandmouse.com: I'm submitting a url like this: http://mysite.com/index.php/alfa/bravo/charlie/delta The index.php calls has code to decode the url segments (alfa/bravo/charlie/delta). It determines that the controller is alfa, the method is bravo, and converts charlie and delta to $_GET['charlie'] = 'delta'. It verifies that the controller and method exist, and calls the controller and method. This works fine. The right controller gets called and the right method, and the GET parameter looks like it should. The method sets some variables and then calls a render() function to render the page, which is in the doc root of the site. The page does get rendered, but without the stylesheet, and none of the graphics show up. Why? Because, according to the logs, Apache appears to be looking for the images and everything else in the directory index.php/alfa/bravo/charlie/delta, which of course doesn't exist. No, I don't have an .htaccess file with RewriteEngine on. Apache figures out that index.php is the file to look for in the original URL, but can't figure out that everything else is relative to that file, not the entire URL. This method is in use in at least one other MVC framework. What am I doing wrong? You need to specify the absolute URL for all assets when using a URL scheme like this because the browser has no idea that index.php indicates the current directory so it resolves relative paths using the full URL. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache odd behavior
Paul M Foster wrote: I'm submitting a url like this: http://mysite.com/index.php/alfa/bravo/charlie/delta Why would you want to do such a thing? If you want parameters in the filename without using get, use mod_rewrite and explode the page name - and use a delimiter or than a / - IE use an underscore, dash, upper case vs lower, etc to indicate your different variables. / has a special meaning in a URL string, I don't understand the motive of wanting to use it as a delimiter in a filename. That calls all kinds of weird issues (like the one you are experiencing, which is because the browser has no way to know index.php is a page - and the browser resolves relative URL's - that's not an apache issue) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache odd behavior
Symfony uses exactly this method for pretty urls. Check it out. Maybe it has everything you want :). Have a look at symfony's .htaccess rewrite rules at least. You have a few possibilities here: You can make ur own rewrite for urls that contain index.php or rewrite http://mysite.com/alfa/bravo/charlie/deltahttp://mysite.com/index.php/alfa/bravo/charlie/deltaas http://mysite.com/index.php/alfa/bravo/charlie/delta and other urls... Or in your framework or cms or whatever have helper functions to get the right urls for images etc. Paths like simply putting img src=/images/myimg.png alt=my img / shouldnt be too hard either. Tim-Hinnerk Heuer http://www.ihostnz.com Mike Ditka - If God had wanted man to play soccer, he wouldn't have given us arms. 2009/2/16 Michael A. Peters mpet...@mac.com Paul M Foster wrote: I'm submitting a url like this: http://mysite.com/index.php/alfa/bravo/charlie/delta Why would you want to do such a thing? If you want parameters in the filename without using get, use mod_rewrite and explode the page name - and use a delimiter or than a / - IE use an underscore, dash, upper case vs lower, etc to indicate your different variables. / has a special meaning in a URL string, I don't understand the motive of wanting to use it as a delimiter in a filename. That calls all kinds of weird issues (like the one you are experiencing, which is because the browser has no way to know index.php is a page - and the browser resolves relative URL's - that's not an apache issue) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache odd behavior
I'm submitting a url like this: http://mysite.com/index.php/alfa/bravo/charlie/delta The index.php calls has code to decode the url segments (alfa/bravo/charlie/delta). It determines that the controller is alfa, the method is bravo, and converts charlie and delta to $_GET['charlie'] = 'delta'. It verifies that the controller and method exist, and calls the controller and method. This works fine. The right controller gets called and the right method, and the GET parameter looks like it should. The method sets some variables and then calls a render() function to render the page, which is in the doc root of the site. The page does get rendered, but without the stylesheet, and none of the graphics show up. Why? Because, according to the logs, Apache appears to be looking for the images and everything else in the directory index.php/alfa/bravo/charlie/delta, which of course doesn't exist. No, I don't have an .htaccess file with RewriteEngine on. Apache figures out that index.php is the file to look for in the original URL, but can't figure out that everything else is relative to that file, not the entire URL. This method is in use in at least one other MVC framework. What am I doing wrong? Paul I assume that in order for this to work you will have to use mod_rewrite for apache to work properly. Check the framework's installation instructions to see if you configured mod_rewrite correctly for this to work properly. -- Thodoris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache odd behavior
On Mon, Feb 16, 2009 at 07:30:57PM +0200, Thodoris wrote: I'm submitting a url like this: http://mysite.com/index.php/alfa/bravo/charlie/delta The index.php calls has code to decode the url segments (alfa/bravo/charlie/delta). It determines that the controller is alfa, the method is bravo, and converts charlie and delta to $_GET['charlie'] = 'delta'. It verifies that the controller and method exist, and calls the controller and method. This works fine. The right controller gets called and the right method, and the GET parameter looks like it should. The method sets some variables and then calls a render() function to render the page, which is in the doc root of the site. The page does get rendered, but without the stylesheet, and none of the graphics show up. Why? Because, according to the logs, Apache appears to be looking for the images and everything else in the directory index.php/alfa/bravo/charlie/delta, which of course doesn't exist. No, I don't have an .htaccess file with RewriteEngine on. Apache figures out that index.php is the file to look for in the original URL, but can't figure out that everything else is relative to that file, not the entire URL. This method is in use in at least one other MVC framework. What am I doing wrong? Paul I assume that in order for this to work you will have to use mod_rewrite for apache to work properly. Check the framework's installation instructions to see if you configured mod_rewrite correctly for this to work properly. mod_rewrite isn't involved. Apache has a lookback feature that looks back through the URL until it finds an actual file it can execute, which in this case is index.php. Unfortunately, it appears that Apache believes the directory in which linked files are found is the *whole* URL. mod_rewrite might resolve this, but it isn't allowed on all servers. So it's not a reliable solution. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache odd behavior
2009/2/16 Paul M Foster pa...@quillandmouse.com: On Mon, Feb 16, 2009 at 07:30:57PM +0200, Thodoris wrote: I'm submitting a url like this: http://mysite.com/index.php/alfa/bravo/charlie/delta The index.php calls has code to decode the url segments (alfa/bravo/charlie/delta). It determines that the controller is alfa, the method is bravo, and converts charlie and delta to $_GET['charlie'] = 'delta'. It verifies that the controller and method exist, and calls the controller and method. This works fine. The right controller gets called and the right method, and the GET parameter looks like it should. The method sets some variables and then calls a render() function to render the page, which is in the doc root of the site. The page does get rendered, but without the stylesheet, and none of the graphics show up. Why? Because, according to the logs, Apache appears to be looking for the images and everything else in the directory index.php/alfa/bravo/charlie/delta, which of course doesn't exist. No, I don't have an .htaccess file with RewriteEngine on. Apache figures out that index.php is the file to look for in the original URL, but can't figure out that everything else is relative to that file, not the entire URL. This method is in use in at least one other MVC framework. What am I doing wrong? Paul I assume that in order for this to work you will have to use mod_rewrite for apache to work properly. Check the framework's installation instructions to see if you configured mod_rewrite correctly for this to work properly. mod_rewrite isn't involved. Apache has a lookback feature that looks back through the URL until it finds an actual file it can execute, which in this case is index.php. Unfortunately, it appears that Apache believes the directory in which linked files are found is the *whole* URL. mod_rewrite might resolve this, but it isn't allowed on all servers. So it's not a reliable solution. 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. For example, if you have a tag like a href=arse.phparse/a and arse.php is in the same directory as index.php you need to change it to a href=/arse.phparse/a. Another example... if you have a href=somedir/crack.phpcrack/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.phpcrack/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. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache odd behavior
On Mon, 2009-02-16 at 20:34 +, Stuart wrote: 2009/2/16 Paul M Foster pa...@quillandmouse.com: On Mon, Feb 16, 2009 at 07:30:57PM +0200, Thodoris wrote: I'm submitting a url like this: http://mysite.com/index.php/alfa/bravo/charlie/delta The index.php calls has code to decode the url segments (alfa/bravo/charlie/delta). It determines that the controller is alfa, the method is bravo, and converts charlie and delta to $_GET['charlie'] = 'delta'. It verifies that the controller and method exist, and calls the controller and method. This works fine. The right controller gets called and the right method, and the GET parameter looks like it should. The method sets some variables and then calls a render() function to render the page, which is in the doc root of the site. The page does get rendered, but without the stylesheet, and none of the graphics show up. Why? Because, according to the logs, Apache appears to be looking for the images and everything else in the directory index.php/alfa/bravo/charlie/delta, which of course doesn't exist. No, I don't have an .htaccess file with RewriteEngine on. Apache figures out that index.php is the file to look for in the original URL, but can't figure out that everything else is relative to that file, not the entire URL. This method is in use in at least one other MVC framework. What am I doing wrong? Paul I assume that in order for this to work you will have to use mod_rewrite for apache to work properly. Check the framework's installation instructions to see if you configured mod_rewrite correctly for this to work properly. mod_rewrite isn't involved. Apache has a lookback feature that looks back through the URL until it finds an actual file it can execute, which in this case is index.php. Unfortunately, it appears that Apache believes the directory in which linked files are found is the *whole* URL. mod_rewrite might resolve this, but it isn't allowed on all servers. So it's not a reliable solution. 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. For example, if you have a tag like a href=arse.phparse/a and arse.php is in the same directory as index.php you need to change it to a href=/arse.phparse/a. Another example... if you have a href=somedir/crack.phpcrack/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.phpcrack/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. -Stuart -- http://stut.net/ I've read through this thread and not noticed anyone mention the base tag. This allows you to specify a URL to which relative ones are mapped to, which could be just what you're looking for, as I believe all the browsers support it (the tag has been around for donkeys years, so I'd be surprised if any browsers didn't support it) Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache odd behavior
2009/2/16 Ashley Sheridan a...@ashleysheridan.co.uk: On Mon, 2009-02-16 at 20:34 +, Stuart wrote: 2009/2/16 Paul M Foster pa...@quillandmouse.com: On Mon, Feb 16, 2009 at 07:30:57PM +0200, Thodoris wrote: I'm submitting a url like this: http://mysite.com/index.php/alfa/bravo/charlie/delta The index.php calls has code to decode the url segments (alfa/bravo/charlie/delta). It determines that the controller is alfa, the method is bravo, and converts charlie and delta to $_GET['charlie'] = 'delta'. It verifies that the controller and method exist, and calls the controller and method. This works fine. The right controller gets called and the right method, and the GET parameter looks like it should. The method sets some variables and then calls a render() function to render the page, which is in the doc root of the site. The page does get rendered, but without the stylesheet, and none of the graphics show up. Why? Because, according to the logs, Apache appears to be looking for the images and everything else in the directory index.php/alfa/bravo/charlie/delta, which of course doesn't exist. No, I don't have an .htaccess file with RewriteEngine on. Apache figures out that index.php is the file to look for in the original URL, but can't figure out that everything else is relative to that file, not the entire URL. This method is in use in at least one other MVC framework. What am I doing wrong? Paul I assume that in order for this to work you will have to use mod_rewrite for apache to work properly. Check the framework's installation instructions to see if you configured mod_rewrite correctly for this to work properly. mod_rewrite isn't involved. Apache has a lookback feature that looks back through the URL until it finds an actual file it can execute, which in this case is index.php. Unfortunately, it appears that Apache believes the directory in which linked files are found is the *whole* URL. mod_rewrite might resolve this, but it isn't allowed on all servers. So it's not a reliable solution. 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. For example, if you have a tag like a href=arse.phparse/a and arse.php is in the same directory as index.php you need to change it to a href=/arse.phparse/a. Another example... if you have a href=somedir/crack.phpcrack/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.phpcrack/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. -Stuart -- http://stut.net/ I've read through this thread and not noticed anyone mention the base tag. This allows you to specify a URL to which relative ones are mapped to, which could be just what you're looking for, as I believe all the browsers support it (the tag has been around for donkeys years, so I'd be surprised if any browsers didn't support it) That should also work, yes. Personally I'd use absolute URLs but each to their own. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache odd behavior
On Mon, Feb 16, 2009 at 08:53:24PM +, Ashley Sheridan wrote: snip I've read through this thread and not noticed anyone mention the base tag. This allows you to specify a URL to which relative ones are mapped to, which could be just what you're looking for, as I believe all the browsers support it (the tag has been around for donkeys years, so I'd be surprised if any browsers didn't support it) You da man! I've never heard of this tag, but it shows up on my Visibone cheatbook, and my HTML 4 reference. Moreover, it works. When the URL in the base tag is specified as: base href=http://mysite.com/; and, for example, a graphic link is done this way: img src=graphics/myportrait.gif It appears to override other considerations with regard to pathing. I've already chosen an alternative solution, but I'll definitely keep this in mind for future reference. Thanks, much. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache odd behavior
On Mon, Feb 16, 2009 at 08:34:22PM +, 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. 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. For example, if you have a tag like a href=arse.phparse/a and arse.php is in the same directory as index.php you need to change it to a href=/arse.phparse/a. Another example... if you have a href=somedir/crack.phpcrack/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.phpcrack/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. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Apache odd behavior
I'm submitting a url like this: http://mysite.com/index.php/alfa/bravo/charlie/delta The index.php calls has code to decode the url segments (alfa/bravo/charlie/delta). It determines that the controller is alfa, the method is bravo, and converts charlie and delta to $_GET['charlie'] = 'delta'. It verifies that the controller and method exist, and calls the controller and method. This works fine. The right controller gets called and the right method, and the GET parameter looks like it should. The method sets some variables and then calls a render() function to render the page, which is in the doc root of the site. The page does get rendered, but without the stylesheet, and none of the graphics show up. Why? Because, according to the logs, Apache appears to be looking for the images and everything else in the directory index.php/alfa/bravo/charlie/delta, which of course doesn't exist. No, I don't have an .htaccess file with RewriteEngine on. Apache figures out that index.php is the file to look for in the original URL, but can't figure out that everything else is relative to that file, not the entire URL. This method is in use in at least one other MVC framework. What am I doing wrong? Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
