This warning technically doesn’t affect or hurt anything but of course after paying for the SSL cert and going through the trouble of installing it, we all want our users to see the green lock icon and not a yellow warning icon!  If you’re running Apache2 the reason for this is that Chrome prefers to use TLS encryption but had to fall back to SSL encryption.  Apache2 supports TLS out of the box but may not be enabled by default.

To enable TLS, open your apache configuration file and add the two lines below:  (The config file is where you previously configured SSLCertificateFile and SSLCertificateKeyFile.  It’s possibly located in /etc/apache2/sites-enabled)

SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

What these lines do is specify that both TLS version 1 and SSL version 3 are supported.  Once you’ve added these lines you need to restart Apache (/etc/init.d/apache2 restart).

If you refresh your browser at this point it’s likely that the warning icon is still there.   Shutting down and re-starting your browser should resolve it.  I suspect that the browser negotiates an SSL connection once and continues to use it until the session expires or the browser is restarted.

1. Install ImageMagick

sudo port install ImageMagick

2. Install imagic module

You’d expect to just be able to run “pecl install imagick” and I would probably try it first.  However the instructions below will work if the automatic installation returns the error: ImageMagick MagickWand API configuration program… configure: error: not found. Please provide a path to MagickWand-config or Wand-config program. ERROR: ‘/private/tmp/pear/temp/imagick/configure –with-imagick=/opt/local/bin/’ failed.

Note version is 3.0.1 in these instructions, adjust the commands depending on the version that is downloaded by pecl.

pecl download imagick
tar xvzf imagick-3.0.1.tgz
cd imagick-3.0.1
phpize
./configure --with-imagick=/opt/local
make
sudo make install

The install process will create a file “imagick.so”, but it may not be automatically installed in the correct location depending on your PHP path settings.  The install will output the location of the .so file so if necessary, you can manually move that file to the extensions directory for your web server.

3. Append to php.ini

extension=imagick.so

That should be it.  Restart Apache and view phpinfo.php. There should be a section for ImageMagick

1.Turn on Apache

Go to System Settings->Sharing and turn on Web Sharing. If necessary click the button that says “Create Home Folder” which will create a folder called “Sites” in your home directory.  You now have a web server that you can access at http://localhost/~username/  (“username” being your own account login name)

2. Edit /private/etc/apache2/httpd.conf

To enable PHP uncomment (remove the number sign at the beginning of) the line:

#LoadModule php5_module libexec/apache2/libphp5.so

(optional) you can re-map the server root to your home website directory by editing DocumentRoot:

DocumentRoot “/Users/username/Sites”

If you wish to use .htaccess files then look a bit further down AllowOverride and set it to “All” like so:

Options FollowSymLinks
AllowOverride All
Order deny,allow
Deny from all

3. Edit /private/etc/apache2/users/username.conf

Your user directory has it’s own permissions as well which are located in this separate file.  You may wish to enable FollowSymLinks and AllowOverride again here by changing these two lines like so:

Options Indexes MultiViews FollowSymLinks
AllowOverride All

4. Copy /private/etc/php.ini.default to /private/etc/php.ini

OSX includes a default php.ini file that you can use but you must rename or copy it first.  If you don’t do this then PHP will still run but it will just be using the default initialization settings with no way for you to override them.

Edit these settings in php.ini (some of these settings will not come into play until they are installed)

display_errors = On
mysql.default_socket = /tmp/mysql.sock
pdo_mysql.default_socket=/tmp/mysql.sock
date.timezone = ‘America/Chicago’
include_path = “.:/usr/lib/php/pear”

5. (Optional) Install PEAR

If you use the PEAR libraries you can install them using the included phar file like so:

sudo php /usr/lib/php/install-pear-nozlib.phar
sudo pear config-set php_ini /private/etc/php.ini
sudo pecl config-set php_ini /private/etc/php.ini
sudo pear upgrade-all

6.  Install MySQL

This doesn’t really require instructions, simply download the latest MySQL from mysql.com.  I installed the 64 bit version.

7. (Optional) Install Apache Plugins

If you use encryption you may need to install mcrypt.  Instructions have been provided by Michael Gracie

If you use the Zend debugger you can install that using these instructions.

Working with SQLite and Flex/AIR Date values can be tricky and various caveats are not particularly well documented. The confusion (for me) is that ActionScript is loaded with UTC functions, and SQLite will happily insert them into DATETIME columns. Everything appears fine, however SQLite does not actually recognize this format as a Date and treats it as plain text. You have no way to see this happened until you try to apply some date formatting functions and notice SQLite returning NULL. SQLite is so lax about data integrity that you can insert anything into any column type and will never receive any warnings. AIR, though, will attempt to cast values behind the scenes based on column types and so you will run into ‘Invalid Date’ errors and weird glitches when attempting to update data.

The magic solution is the Julian Date Format which both SQLite and AIR recognize as a date value. This is somewhat surprising as ActionScript has no built-in support for outputting Julian dates. If you’re like me, you may have already hacked up workarounds using int fields with timestamps, however your matching ActionScript class properties have to be hacked to match, and the hacking can trickle down throughout your code. This also prevents you from using the SQLStatement.itemClass functionality, which is nice when using Cairngorm, DAOs, value objects, etc.

To avoid the pain follow these rules when working with dates:

1. If you want a strongly typed Date field in AIR, the relevant SQLite column must be defined as DATETIME.  The interesting thing about this is that DATETIME is not technically a recognized SQLite column type and according to the SQLite docs it will be considered numeric.  But AIR is obviously looking at the column definition somewhere in the framework because it will refuse to automatically cast any value where the column type is not DATETIME.

2. Whenever inserting or updating DATETIME fields, you must store it in Julian format (or NULL).  SQLite will happily accept many common date formats. However AIR will behave inconsistently. Here is how to insert Julian dates in a variety of ways:

Inserting a Julian date manually via SQL:

To do this, simply have SQLite format your date value to Julian format using ‘%J’

UPDATE my_table SET my_column = STRFTIME('%J','2008-01-02 03:04:05')

Inserting a Julian date via AIR (with parameters):

Parameters are the best way to build SQL statements as you can use strongly typed Date variables and AIR will deal with the formatting for you.

statement.text = "UPDATE my_table SET my_column = :my_value";
statement.parameters[":my_value"] = new Date(2008,0,2,3,4,5); // Jan 02, 2008 03:04:05

Inserting a Julian date via AIR (without parameters):

If you are not using parameters, you have to pre-format the date into something that SQLite can parse. This is surprisingly obnoxious and requires you to write a couple of helper functions. (Note – if you know of an easier way to do this, please post a comment.)

public function lpad(original:Object, length:int, pad:String):String
{
var padded:String = original == null ? "" : original.toString();
while (padded.length < length) padded = pad + padded;
return padded;
}

public function toSqlDate(dateVal:Date):String
{
return dateVal == null ? null : dateVal.fullYear
+ "-" + lpad(dateVal.month + 1,2,'0')  // month is zero-based
+ "-" + lpad(dateVal.date,2,'0')
+ " " + lpad(dateVal.hours,2,'0')
+ ":" + lpad(dateVal.minutes,2,'0')
+ ":" + lpad(dateVal.seconds,2,'0')
;
}

var myDate:Date = new Date(2008,0,2,3,4,5); // Jan 02, 2008 03:04:05
statement.text = "UPDATE my_table SET my_column = strftime('%J','" + toSqlDate(myDate) + "')";

Fudging data to work around AIRs validation

If you absolutely refuse to change your schema (for example you insist on using timestamps, or you have to maintain compatibility with other clients) you can get AIR to play along during READ operations by altering your select statement like so:

SELECT STRFTIME('%J',my_column) as my_column from my_table

This does assume that the data is in a format that SQLite recognizes as a date. If SQLite can’t parse the date value, then it will just return NULL. For hilarity sake, you can also use this ridiculous date format which surprisingly works with AIR. A word of warning about this workaround is that, even though you will be able to read data, you may not be able to update data via SQLCommand parameters if your column types are DATETIME because AIR will complain about an invalid date (see errors below). You will have either have to write your own SQL statements without parameters or else change your column types to int or varchar.

Formatting a Julian date manually in SQL so you can read it:

Julian values are great and all that, but it’s pretty much impossible to eyeball them when you’re working at the command line. SQLite recognizes Julian formatting as a valid date, so you can use the STRFTIME function to format and output it any way you like. Below is a simple example that is easier to read:

SELECT STRFTIME('%Y-%m-%d %H:%M:%S',my_column) as my_column_formatted FROM my_table

Common errors that occur while working with dates:

Invalid Date

You may see this in a DataGrid instead of the expected date value. This is because you have a DATETIME column in SQLite, however the value is not in Julian format. Even though SQLite may recognize it as a date value, AIR does not. The solution is to clean your data so that all dates are Julian format, or alternatively change the column type to VARCHAR.

‘Error #3115: SQL Error.’, details:’could not convert string value to date’

This error occurs when you try to update a record that has one or more DATETIME columns that do not have the date stored in Julian format. The weird part is that even if you are not touching that specific column in your insert/update statement – AIR will still validate the Date and throw this error. The solution is to clean your data so that all dates are Julian format, or alternatively change the column type to VARCHAR.

If you have any tips or corrections please post a comment and I’ll incorporate it into the article.

Steps to Fix the Problem:

Before you troubleshoot further, you may want to read #5 about how the Application Pool effects PHP configuration changes.

1. Replace the old DOS format path to the PHP Executable with a full path w/ quotes
2. Move php.ini to C:\Windows
3. Edit php.ini to set cgi.force_redirect = 0 (only necessary for CGI mode)
4. Make sure php-cgi.exe and/or phpisapi.dll are included in Web Service Extensions
5. Recycle the Application Pool

1. Replace the old DOS Path Format

The default path to PHP is C:\Program Files\PHP. When creating the IIS extention mapping, the PHP Installer uses the old DOS format path to the PHP ISAPI or CGI executable such as “C:\PROGRA~1\PHP\PHP5IS~1.DLL”. IIS does not seem to like this format.

One simple solution for this is to simply reinstall PHP to C:\PHP, or another location that doesn’t use long filenames. This will generally save you a lot of grief as PHP and its installer do not seem to handle windows long file names consistently.

If you prefer to keep things in Program files, go to the IIS Extension Mapping screen and locate the value for “.php” (See screenshot above). Click the browse button, select the executable and put quotes around it the entire path. So the value for this field should look like this “C:\Program Files\PHP\php5isapi.dll” (WITH the quotes around it). If you have installed PHP in CGI mode instead, the file name would be php-cgi.exe instead of php5isapi.dll

While you’re at it you may want to check the box for “Verify that file exists” as well. This allows IIS to handle actual missing pages (ie broken links) and return a 404. Otherwise IIS will just pass the request to PHP without verifying the .php file really exists and PHP throws a CGI error when the file isn’t found. People seem to have inconsistent results with this setting.

If you recycle the app pool at this point (see step #5) you *may* solve the 404 error depending on what extensions you installed or whether you had re-run the installer and changed stuff. However, you may still have issues changing php.ini settings in which case keep reading.

2. Copy php.ini to C:\Windows

The PHP installer creates a php.ini file for you based on your selections in the setup process. However the installer saves the file in C:\Program Files\PHP. The problem is that PHP is looking in C:\Windows for the .ini file. So, you need to move the file php.ini to C:\Windows. This may be confusing because PHP seems to run fine. But if you look closely at the phpinfo() output, you may find that php.ini file is not being loaded and all default settings are being used.

One of the critical things when configuring PHP is to actually edit the .ini file that is being used by PHP. The installer creates a worthless file in a location that PHP won’t read and so you may waste a lot of time editing this file. PHP pretty much universally will check the Windows folder for php.ini on all varieties of Windows, so my advice is to use that location and delete any other php.ini files that are hanging around..

3. Set cgi.force_redirect = 0 (Only necessary for CGI mode)

Various people report that you need to edit php.ini and set:

cgi.force_redirect = 0

I haven’t noticed this setting having any effect on my installations, but many people claim it is necessary when you are running PHP in CGI mode. This setting will have no effect if you are running in ISAPI mode.

4. Make sure php-cgi.exe and/or phpisapi.dll are enabled in Web Service Extensions

In IIS Manager, click on “Web Service Extensions” This includes a list of all dll and exe files that IIS is allowed to execute. The extension mapping that is specified for .php files must also be added here. I prefer to just add both php-cgi.exe as well as php5isapi.dll here and enable them both so that if I don’t need to worry about it again.

If the handler is already in the list, make sure that it is “enabled” as well. The enabled services have a green overlay on the service icon.

Lastly, confirm that the file path is exactly the same here as it is in your .php extension mapping configuration. That includes the dos path formatting. If you use junctions, you need to be using the same path in both places. IIS seems to check the path rather than the executable. It will not recognize if you use a slightly different path, even if they both point to the same executable.

5. Recycle the Application Pool

In order for any PHP configuration changes to take effect in Windows 2003, you need to recycle the Application Pool. If you have made changes to php.ini and they don’t seem to take effect, this is likely the reason. Among other things, the pool caches PHP settings and you need to clear it before new configuration settings will take effect. You’ll read people telling you to restart IIS (which doesn’t recycle the app pool) or even reboot your machine (which is overkill). You don’t need to do either of those. Just right-click on the DefaultAppPool in the IIS management interface and “Recycle” is one of the options.

If I’m having trouble with the ini file, I like to have a typical phpinfo.php file on the server while I make some arbitrary change to the php.ini file (like the session timeout or the max upload size). I refresh phpinfo.php and verify that my changes are taking effect. You can also check the Windows Event logs under “System” which will sometimes report errors in the php.ini file.

Notes regarding re-running the PHP installer to make changes:

The PHP installer does not really handle changes all that well. For one thing it will overwrite the path to the PHP executable w/ the old DOS format so you need to fix that after you run it.

The 2nd thing is that it will write changes to C:\Program Files\PHP\php.ini – regardless of the fact that PHP is actually looking at C:\Windows\php.ini

If you had previously moved php.ini to the windows folder, when you run the Change installation feature, it will create a fresh php.ini file that only incorporates the most recent changes. (ie, if you had 10 extensions enabled and you make a change to enable 1 more, your new php.ini file will only have the 1 enabled and the previous 10 will no longer be enabled)

One way around this is to temporarily move C:\Windows\php.ini file to C:\Program Files\PHP. Then run in installer to make changes. The installer will write changes to php.ini in that location. Then, move php.ini back to C:\Windows.

This particular error can occur when you haven’t selected .NET 2.0. in the application settings.

Windows 2003 Uses Application Pools which can only support one version of the .NET framework at a time. If you are running both 2.0 and 1.0 applications on the same 2003 server then you have to create at least two application pools – one for each version of the framework. All of your 1.0 apps should be configured to use one pool and the 2.0 apps will use the other. The pool itself isn’t configured to specify which version it will support, but the app that starts first will “grab” the pool and lock it down to whatever version of the framework that particular app uses.  So if you have a 1.0 and 2.0 in the same pool, it will be a race between the two apps to see which can grab the pool first.  The winner will run fine and the loser will crash.  When IIS restarts, the race starts again.

This will run PHP in CGI mode for both IIS and Apache.

1. Download from www.php.net the Windows Installer version of PHP AND the Windows “manual install” .zip distribution. (If you already have PHP running for IIS, then you only need the zip version)

2. Run the PHP installer. Install it to its default location of C:\PHP. PHP should now be working with IIS.

3. Move the file C:\PHP\php.ini-dist to C:\Windows\php.ini

3. Unzip the “manual install” distribution. You’ll notice that it has much of the same files as are already in C:\PHP. Move all the of extra directories contained in this .zip to C:\PHP

4. Download and install Apache HTTP server from www.apache.org. (I used version 2). Default install location is C:\Program Files\Apache Group\Apache2. The configuration you use is up to you, but i specify in the install wizard to run Apache manually on port 8080 so that it will co-exist with IIS (which is already on port 80). Then after that is done, I install it as a service by executing the command-line command: apache -k install
(from within the apache2\bin directory)

5. Edit the Apache configuration file C:\Program Files\Apache Group\Apache2\httpd.conf – make the following changes:

# search for “DirectoryIndex” and add index.php to the end:
DirectoryIndex index.html index.html.var index.php

# search for “ScriptAlias” and add the following lines in that section:
ScriptAlias /php/ “c:/php/”
AddType application/x-httpd-php .php
Action application/x-httpd-php “/php/php.exe”

6. restart Apache and the new configuration should take effect. create a test PHP file and see how it works.

* caveat: if you use the same browser and surf back-and-forth between IIS and Apache, you may get a bunch of weird error messages about permission denied while writing session files. This is because Apache and IIS run as different users & they will block each other from writing to the same session file.

I find a lot of surprising security problems as I work on client’s sites. Even large, reputable companies often have gross security issues. I know more than anyone how difficult it can be to get a cgi script installed and working. It’s tempting to walk away without double-checking the security. One of the most common things that I see is poor security of the cgi-bin. Depending on the setup of your server, someone can take total control of your account easily through a poorly secured cgi-bin.

The particular problem i’m writing about involves writable files/directories within your cgi-bin, or scripts that make calls to external programs (like sendmail). These are both very common types of scripts that you would find in just about any cgi-bin.

The writable file issue is that most cgi scripts rely on a datafile to store their information. In some cases, they need an entire writable directory to store data (file uploads, etc). The tricky part is that you have to allow the script write access to the file/directory. If your server is running as “nobody” then you need to allow world write access to the file. This is dangerous because other users on the server also have the ability to run under the “nobody” user – which means they can also write to those files. Some servers are configured so that scripts execute under your own userid. Otherwise sensible people are fooled into thinking that they are protected by this. Although it does protect you from the “nobody” exploits, it actually make the potential damage much worse if you have poor security settings.

The issue with scripts that make calls to external programs (like Formail for sending email via sendmail, etc) is that if they are not coded properly, someone can input malicious text that causes an arbitrary shell command to run in addition to the sendmail command. This command will run under whatever userid that the original script has.

One dangerous situation is a script that allows file uploads and it’s writable directory is in the cgi-bin. Any script like this should have serious security checks in place to prevent malicious files from being uploaded. If the script doesn’t check file types as they upload, any anonymous user can upload a script or executable file right to your cgi-bin.

Another situation is on a virtual host where you share your account with lots of other users. This exploit is only available to people who have an account on your machine, however it is no less a problem. All users on your server can install cgi scripts in their account which run under the “nobody” permissions. If they install a simple command processing script, they can manipulate any file in your account that allows world write access.

So, take a look at your cgi-bin and look for any writable files or directories. Imagine what would happen if someone could edit or add any file there in your cgi-bin. A writable directory is particularly bad because the other person on your server can actually write a new script file there and then browse to the url to execute it.

Normally if someone can totally compromise your site in this way, they are limited to running as the user “nobody.” However, there is still quite a bit of damage that can be done. Formmail scripts can be installed to send spam. Scripts to snoop into your datafiles can be installed. Large files can be uploaded and shared (using your bandwith). I once had a client who incurred a $10,000 bandwidth bill after their server was compromised by hackers sharing video game software. Nothing more than “nobody” access is needed to do this.

If cgi-wrap is enabled, the situation is compounded because the scripts in your cgi-bin can be executed through cgi-wrap to run under your own userid. At that point, they own your account.

How To Secure cgi-bin:

There’s a few simple things that can help lock down your cgi-bin.

1. Never, ever have a file with both world-execute and world-write permissions. This can be overwritten with any arbritrary code by any user on your server. Once they overwrite, they can execute it through the browser. Scripts themselves should never require write permission. Read/Execute is fine (chmod 505 is nice and secure).

2. If possible, never have any writable directories or files in the cgi-bin. Not even writable by your own user id. there is no reason that a file needs to be writable within the cgi-bin. Depending on what scripts you have installed, this can be challenging. The solution is to move all datafiles to an area that is not accessible through the web browser. If this is not possible, see # 3

3. If you must have writable files or folders in the cgi-bin because of the functionality of a script, keep them in a subdirectory and put an .htaccess file in there that has the contents “deny from all” in it. Your scripts can still read/write files there, but nothing can be executed through the browser. if you are not able to put them in a separate directory, you can deny access to specific files using .htaccess.

4. Never give any permissions to the “group.” In UNIX you have three permissions to grant – owner, group, world. for example, chmod 644 grants 6 (rw) to owner, 4 (r) to group and 4 (r) to the world. The group is almost always other accounts on your server. You generally do not know these other users and there is no reason to give them any permissions for any file in your account. The middle value should always be zero. for example: chmod 604 gives the group 0 (no access) which is fine.

5. be very careful when cgi-wrap is enabled or your cgi-bin executes using your own account’s userid. in this case you have to make sure that nothing can be written arbitrarily into your cgi-bin even using your own account permissions. Keep in mind that you do not need permission to write to a script. You can remove the write permission even for yourself. If you need to change it later, you first change the permission to allow write, then change it back. It doesn’t need to sit there with write permissions. You have to be very cautious about what scripts are installed, because any script with an exploit can be dangerous. if someone can write or upload to your cgi-bin, they can create their own script and run it under you userid. If you use cgi-wrap, there is no reason for the group or the world to have any permissions on your files. so, you should change permissions something like this: chmod 400 (only you have read permission). scripts can be chmod 500. writable datafiles can be chmod 600, but should not be stored in a public area. remember that if someone can run arbitrary code as your userid, they own your account!

6. Try to break into your own account. Go through your scripts and try to upload a file that shouldn’t be allowed. Look at scripst that send email and see if you can enter data in such a way that code gets executed.

Summary:

The moral of the story is to be cautious with your cgi-bin. Especially look for writable files and directories. Never trust other users on your server. It may not seem important to take security seriously for your homepage with a bulletin board and formmail script. But there are malicious people out there always scanning for easy targets. Your data can be compromised or your bandwidth stolen – leaving you with the bill. A little bit of extra time can save you a lot of grief later.

This is a walkthrough to install subversion server on Windows and make it available over http using Apache. Subversion is a version control system. In combination with Apache, you can allow local and remote developers to share source code.

This guide will use the following installation paths. You can change these as you like, but I’m going to use them in this walkthrough:

Apache = C:\Program Files\Apache Group\Apache2
Subversion = C:\Program Files\Subersion
Location of Repositories: C:\InetPub\svn\
Location of passfile: C:\InetPub\svn.pass
URL for Repositories: [url]http://localhost:8080/svn/[/url]

1. INSTALL APACHE

a. Download Apache from http://httpd.apache.org/download.cgi (Apache 2.0.55 is the current stable release at the time of this writing)

b. Run the Windows Installer. The defaults are fine. When you reach the Server Information dialog, you’ll be prompted to choose between installing on port 80 as a service, or on port 8080 with manual startup. Choose the service option on port 80 (we will change the port in the next step). Complete the install process accepting all defaults.

c. Since we are working on a Windows server, you probably already have IIS running on port 80. So, we need to pick another for Apache – this is really easy to change. Open the file C:\Program Files\Apache Group\Apache2\conf\httpd.conf in notepad.exe. Do a find (ctrl+f) for the word “listen” until you fine the line

Listen 80

Change the 80 to 8080 (or whatever port you want). For this example, I’m going to be using port 8080

d. Save http.conf and restart Apache to reflect the changes. You can do this through the services applet (Start -> Run services.msc) or also through the apache service monitor (This is the apache icon next to the clock in the taskbar)

e. Test that Apache is running by going to [url]http://localhost:8080/[/url] (you should get the default Apache welcome screen).

2. INSTALL SUBVERSION

a. Download The subervsion server binary for Windows. It’s currently located at http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91
For these instructions, download the svn-x.x.x-setup.exe installer.

b. Run the Subversion server setup. All defaults are fine. At a certain point you’ll see an option about installing Apache Modules. As far as I can tell this does nothing, but whatever! I left it checked.

3. CONFIGURE APACHE SUBVERSION MODULES

a. We need to move the subversion modules so Apache can use the. To do that, copy the following files from C:\Program Files\Subversion\bin\ to C:\Program Files\Apache Group\Apache2\modules\

libdb42.dll
libeay32.dll
mod_authz_svn.so
mod_dav_svn.so

b. Open C:\Program Files\Apache Group\Apache2\conf\httpd.conf again and do a find for “LoadModule” – This should take you to a section where there are a bunch of LoadModule statements uncomment this line (delete the # from the beginning of the line):

LoadModule dav_fs_module modules/mod_dav_fs.so

Below that, add the following two lines:

LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so

Now scroll to the very botton of the file and paste the following.

<Location /svn>
DAV svn
SVNParentPath C:\InetPub\svn
AuthType Basic
AuthName "Subversion repositories"
AuthUserFile C:\InetPub\svn.pass
#AuthzSVNAccessFile svnaccessfile
Require valid-user
</Location>

You can change these as you like, however this is what I’ll use for the instructions here. I happen to think these are reasonable defaults. The settings are probably somewhat self-explainitory, but for additional information read the fine Apache manual.

c. Restart Apache Again to load the configuration changes

d. Test that everything is working at this stage by going to [url]http://localhost:8080/svn/[/url] You should get prompted for login box. We haven’t created a username/password yet so just hit cancel.

4. CREATE A USERNAME/PASSWORD FOR HE APACHE DIRECTORY

a. We need to use htpasswd.exe in the Apache2/bin directory to edit the password files. this is a pain unless it is in your path, so I recommend adding it to your environmental PATH variable. (right-click My Computer -> Advanced -> Environmental Variables) Append the folling to the PATH variable: ;C:\Program Files\Apache Group\Apache2\bin

b. Create a blank file C:\InetPub\svn.pass

c. Open a new DOS windows (you need to open a new one to recognize the PATH changes)

d. go to C:\InetPub and type the following:

htpasswd snv.pass svnuser

You’ll be prompted for a password. enter whatever you want (svnpass for this example)

(This is the procedure you can repeat to add more users)

e. You can open svn.pass in notepad to make sure there is a user there – you should see “svnuser” followed by the crypted pass information.

5. CREATE A REPOSITORY

a. Open Windows explorer and create a folder C:\InetPub\svn

b. Open a DOS window and go to C:\InetPub\svn

c. Enter the following:

svnadmin create myrepository

(You can repeat this process to create additional repositories – I am just choosing the name myrepository for testing purposes)

d. Give it a test by opening [url]http://localhost:8080/svn/myrepository/[/url] and entering the username/pass you created in step 4 (in this example svnuser / svnpass) If everything is working right, then you should see “Revision 0″ in the browser.

Contratulations – You’re Done!

6. USING YOUR REPOSITORY

If you need instructions for using subversion, I’d recommend downloading TortoiseSVN from http://tortoisesvn.tigris.org/ and reading the documentation. Although setting up the server is a bit of work, using the client is pretty easy.

When you use your client to connect to the server, your subversion repository will always start with http://your.domain.com/svn/ (as opposed to some public repositories that start with svn://your.domain.com/) Otherwise, the usage is exactly the same.

If you haven’t managed a Subversion server, you may not know how to initialize your repository. Basically, each time you create a new repository, you have to initialize it by doing an import. You have to add at least one file to the repository. To do this, just create a blank folder on your computer, put at least 1 file in there (I put a readme.txt or whatever). Then use your subversion client “import” command. This will initialize the repository at version 1. At that point, you can check in and out as you always do.

THE END

This seems to relate to an earlier bug reported by Microsoft with IE 6 where the content length was reported as 0 during POST requests. This occured when browsing sites running UNIX/Apache with keepalive enabled. However, I’ve discovered that the same problem occurs intermittently with certain PHP applications and GET requests.

One workaround which solves the problem (although with a performance hit) is to create an .htaccess file in the root directory with the following setting:

[code]
BrowserMatch "MSIE" nokeepalive downgrade-1.0 force-response-1.0

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
[/code]

This workaround disables keepalive for all IE 6 clients. I imagine this would have a negative performance effect, however it is likely preferable to a buggy application.

I haven’t been able to determine if certain PHP code techniques could be causing the problem. I read certain people presuming that it could be session related, however, i went as far as removing all session functionality from an application, however it did not solve the problem.