Please help... http://localhost/test.php

To confirm, is this computer running Mac OS X Server, or is this Mac OS X client? (This is the server discussion forum, though the reference to "Web Sharing" implies the client variant.)

Hour after Hour, same message... The requested URL /test.php was not found on this server.
Using: http://localhost/test.php (file is actually in my Sites folder)

Where is the request coming from? Check the Apache access logs here. Are you requesting the file? Or is the request from remote?

Even if I drag and drop it on Safari or Firefox, I get this message.

Drag and drop what to where?

If you're loading files into the web directories, ensure the files and the directories are readable by Apache, but are not writable by and not owned by Apache.

Web Sharing is on, Apache server is running, MySQL is running, same file serves up fine from the web. It's the <?php phpinfo() ?> test file everyone uses to check MySQL/PHP server.

And more than a few attacks look for this file, too.

Also troubled with protocol for "root folder" address. Is it localhost or localhost/Users/~long_name/etc.... nothing is working.

http://localhost/~shortname

Various of the client environments and configurations block access outside the web directories, too. (Usually deliberately and by default.)

Any ideas or suggestions???

We are (well, OK, maybe I am) going to need a few more words around what you're trying to do, and what you're seeing here. Some more details here will help.

Hour after Hour, same message... The requested URL /test.php was not found on this server.

Using: http://localhost/test.php (file is actually in my Sites folder)


By default, if you haven't reconfigured apache, then http://localhost/test.php will attempt to serve the document /Library/WebServer/Documents/test.php

Therefore putting the file in your local directory is the problem.

You should move the document to the above directory, or change the URL you're accessing. To access a file in your personal Sites directory you need to use the form:

http://localhost/~username/test.php

The addition of the ~username tells Apache to look in the specified username's Sites directory, not the standard /Library/WebServer/Documents/

The below example is not working when typed into a browser...

Of course that won't work. That would be a security nightmare if users could type in any path to any file on your machine.

Apache is specifically configured to serve files from specific directories only. By default that's /Library/WebServer/Documents and individual users' ~/Sites directories.

There are two ways of getting Apache to serve content outside of these paths.

One is to create a symlink to the other content (and tell Apache to follow symlinks, which it doesn't do by default).

The other is to create an alias in the configuration. An alias tells Apache to serve content from a different directory when specific URIs are seen.

For example, if you want to serve any http://yoursite.com/media/ URIs from a second volume you could add an alias for /media/ that points to the other volume, like:

Alias /media /Volumes/OtherDisk/folder

Now Apache will take any URI that begins with /media and serve that request from /Volumes/OtherDisk/folder rather than from the normal document root (e.g. /Library/WebServer/Documents)

You can use Server Admin to add such aliases, or edit the site's configuration file directly.

And for the direct question (Camelot is entirely correct about access control here; if this server is internet-facing, you will get attacked and you will find php is a very popular attack target), the %20 character is space character in URL encoding.

Create a space-containing file in your default ~ directory (or somewhere else that the web server can touch), and you should be able to access it with file%20name.html or whatever you've named it.

THIS SOUNDED GOOD AT THE TIME... but as I mentioned, I now get the message "access denied to root@localhost" ----HELP!!!

You either haven't configured your MySQL database correctly or, at the very least, you're not using a valid username/password that it recognizes.

It sounds as though you've now got your web application talking to MySQL. But your web app (PHP in this case) is trying to connect to MySQL using the 'root' username. MySQL doesn't permit this by default.

You either need to grant privileges to 'root' to query/update the table or, more correctly, configure your web app to use a more restricted account that has the permissions you need (generally running queries under a root account is discouraged).

For example, you might configure a 'phpuser' account with a password, then change your webapp to connect to MySQL using that password rather than root.

This is all well documented in MySQL's installation guides since granting privileges is a basic prerequisite of running databases.

With all due respect, you are in over your head.

I mean that nicely, but you're asking for help with step (say) 7 & 8, but you're not understanding steps 1,2 & 3. There's probably nothing wrong with Dreamweaver,
your obstacles lie much earlier on in terms of setup/configuration.

The symlink ("alias" in your words but they're not quite the same) is one possible avenue for addressing differences in a stock MySQL setup vs. what Apple does & why & for good reasons.
Did you search Apple support ? See http://support.apple.com/kb/TS1999
But that has nothing whatsoever to do with your MySQL users, passwords & access rights.

You might wish to hire someone that can help you get this setup correctly and configured securely.
By default, after/apart from certain configuration setup/options, you should not ever connect as root to your SQL database (nor ever use that connection method for PHP, barring something seriously locked down and knowing full well what you're doing and why).

The tasks that you're facing are not difficult in and of themselves, but do require a modicum of understanding local vs network connections, restricting either per the service in question,
and basic database functionality.
There's plenty of documentation at the MySQL site, you'll want to look for "Securing the Initial MySQL Accounts" and be sure to verify that this is enacted for your setup.
Then you'll want to understand that MySQL has its own set of users, passwords & access-rights,
distinct from (by design !) your server/OS X accounts.