I like using Subversion to deploy web content to production servers. I check in everything while I’m working on the development copy, then check out onto the server when it’s ready.

Subversion creates a .svn directory contain readable copies of all your files, which is bad for server-processed files like .php or .aspx that you don’t want readable by, say, Google Hackers.

I have thought about this before but when I went to do it I couldn’t find any clear guides online. I did find this question at Server Fault, which is a newish sister of Stack Overflow, which reminds me kind of Experts Exchange but without the suck. Except that in this case the answers sucked. So I figured it out and added my answer and am posting it here too:

“Don’t do it that way” does not answer the question.

Practically, I like having a working copy on the production server, because that way I can make quick changes in production (who has never done that?) and check them back in. It depends on where you want your security/convenience slider, and in many cases this is a good place.

The standard solution in Apacheland is to leave the .svn files there but tell the web server to never serve them. Here’s how to do that with IIS 5 through 7 on Windows NT4 through 2008.

1. Download and install ISAPI_Rewrite — the Lite version will be enough for this purpose. There are two versions, version 2 and 3. Use ISAPI_Rewrite3 unless you need to support NT4. Also, note the extra IIS features you need to enable for Win 2008.
   Warning– the MSI installer may stop and start IIS.

2. Launch the Helicon->ISAPI_Rewrite3->ISAPI_Rewrite Manager app from the Start Menu. It makes editing the config file (installed in C:\Program Files\Helicon\ISAPI_Rewrite3\httpd.conf by default) easier, but you can also do it by hand. note, the config file in ISAPI_Rewrite2 is named httpd.ini and is read-only by default.

3. Add these lines to httpd.conf:

# Deny access to Subversion working copy administrative
#  directories (.svn) and their contents
RewriteRule .*/\.svn\b.* . [F,I,O]

Now, any request for a .svn directory or its contents will result in a 404 Not Found from the server.

The documentation is good, but I want a simpler recipe that also accounts for all the forseeable errors, even those that don’t get to Symfony. Some details vary by version, but in short, for symfony 1.1:

Test URLs

We want to ultimately make sure that these URLs behave the right way:

Normal errors (must have)– 404 Not Found and 500 Server Error

I have seen error 500 pages countless times during app development, but I just could NOT reproduce one to test the 500 error page. Any quick recipes for that, anyone?

More esoteric error conditions– app unavailable/locked, module disabled

all:
  enabled:     false

Steps

1. manually create a few files for the default module. DO NOT use symfony generate:module because you only want to override a small bit of the built-in default module (found in /path/to/symfony/lib/controller/default/templates/* incidentally, if you ever want to see what you’re overriding).

   $ mkdir apps/frontend/modules/default
   $ mkdir apps/frontend/modules/default/config
   $ mkdir apps/frontend/modules/default/templates
   $ touch apps/frontend/modules/default/config/view.yml
   $ touch apps/frontend/modules/default/templates/error404Success.php
   $ touch apps/frontend/modules/default/templates/disabledSuccess.php

2. Edit the templates I just made– remember, the content for these goes inside your sitewide layout.php. I started out by copying the default templates in lib/controller/default/templates/ from my Symfony distribution.
3. create mostly static pages for web/errors/error500.php and unavailable.php*** They won’t be wrapped in layout.php so they need to have the full page structure, and basically no symfony-involving PHP code (like helpers, too bad), though I do use a bit of really basic stuff, like including the URL in my mailto form on the 500 page:

     <dl class="sfTMessageInfo">
       <dt>Something is terribly broken.</dt>
       <dd>
   	  <p>
   Please 
   <a href="mailto:webmaster@mycompany.com?subject=500 error at http://
   <?php echo $_SERVER['SERVER_NAME'] . '/'. $_SERVER['REQUEST_URI']  ?>
   <?php 
   if (array_key_exists('HTTP_REFERER', $_SERVER)) {
     echo "&body=Referrer: ".$_SERVER['HTTP_REFERER'];
   }
    ?>">
   e-mail us at webmaster@mycompany.com</a> and let us know what you were doing when this error occurred. We will fix it as soon as possible.
   </p>
   	  <p>
      If you have an urgent problem, please call the Support Desk at XXXX.
   </p>
   	  <p>
      You may also find the <a href="/README.html">documentation</a> useful.
   </p>
   </dd>
   </dl>

4. Include my stylesheets, in view.yml:

   error404Success:
     metas:
       title:        ED Log 404 Not Found
     stylesheets:
       - -*
       - mystyles1: { position: last }
       - mystyles2: {position: last}
       - /sf/sf_default/css/screen.css
       - /sf/sf_default/css/ie.css
       - errors: {position: last}
   

   (and the same thing for disabledSuccess:) My web/css/errors.css overrides some of the default symfony error page styles (compare web/sf/sf_default/css/screen.css in your symfony distribution) to make them less brown, but I keep the general thing.
5. If your application has security on by default, make sure to un-secure the error pages so people can see them without logging in. Add these above the default rule in apps/frontend/config/security.yml:

   error404:
     is_secure: off
   
   disabled:
     is_secure: off
   

6. Tell Apache where to find total 500 errors and 404 errors that don’t make it to symfony (like anything that doesn’t get to a front controller, like a misspelled controller or image name):

     <Directory "/var/www/my_sf_app/web">
           ErrorDocument 404 /default/error404
   	ErrorDocument 500 /errors/error500.php
     </Directory>

7. Hrm, the table of URLs above sounds like a good test script… BUT, it resists scripting because most of the error URLs are outside symfony, so you don’t get the custom error pages when going to an actual error with sfTestBrowser, or even a regular sfBrowser, because instead you get fancy exception stuff. So, here’s a pretty lame test script I put in test/functional/frontend/customErrors.php that tests the easiest cases, but it’s not hard to manually try the others with a browser. I welcome suggestions for improvement!

    
   <?php
    
   include(dirname(__FILE__).'/../../bootstrap/functional.php');
    
   $e404_regexp = "webmaster@mycompany";
   $disabled_regexp = "xXXXX";
    
   // create a new test browser
   $browser = new sfTestBrowser();
    
   /* http://localhost/myapp/default/error404	 
   The "real" 404 page */
    
   $browser->
     get('/default/error404')->
     isStatusCode(404)->
     isRequestParameter('module', 'default')->
     isRequestParameter('action', 'error404')->
     checkResponseElement('body', "/$e404_regexp/");
    
    
   /* http://localhost/myapp/default/disabled	 
   The "unavailable" page for when symfony is locked with symfony project:disable */
    
   $browser->
     get('/default/disabled')->
     isStatusCode(200)->
     isRequestParameter('module', 'default')->
     isRequestParameter('action', 'disabled')->
     checkResponseElement('body', "/$disabled_regexp/");

   And a few passing tests is better than none, right?

   $ php ./symfony test:functional frontend customError
   # get /default/error404
   ok 1 - status code is 404
   ok 2 - request parameter module is default
   ok 3 - request parameter action is error404
   ok 4 - response selector body matches regex /webmaster@mycompany/
   # get /default/disabled
   ok 5 - status code is 200
   ok 6 - request parameter module is default
   ok 7 - request parameter action is disabled
   ok 8 - response selector body matches regex /xXXXX/
   1..8
    Looks like everything went fine.
   

Sheesh, it’s still a little too involved for such a small benefit. If anyone has any ideas on how to streamline this procedure, let me know! Maybe it could be a plugin or an enhancement to symfony?

• Disabling projects only works if the check_lock option is enabled in e.g. apps/frontend/config/settings.yml

** Symfony 1.0 default templates are found in …/symfony/data/modules/default/templates/ and include an ‘unavailable’ template in addition to ‘disabled’. Symfony 1.2 templates are in the same place as in 1.1.

*** Symfony 1.2 wants its 500 error page in config/error/error.html.php

The Problem

Sometimes a parameter in a GET string contains slashes, which are interpreted as file path delimeters by Apache and/or parameter name/value separators by Symfony.

So this URL works: http://myapp/employee/bytitle/title/System+Engineer

But this one returns a 404 (Page Not Found) error: http://myapp/employee/bytitle/title/Programmer/analyst

Wrong solution

Double-escaping the slash into ‘%252F’ (e.g. urlencode(str_replace('/', "%2f", $this->getTitle()))) works if the URL isn’t rewritten by Apache.

This threw me because my URLs would work if they included the name of the controller file, frontend_dev.php or backend.php or even index.php like http://myapp/index.php/employee/bytitle/title/Programmer%252Fanalyst,

but they wouldn’t work through the implicit, controllerless URLs like http://myapp/employee/bytitle/title/Programmer%252Fanalyst

Right solution

Both

1. Turn on the AllowEncodedSlashes Apache directive by adding this line to your server-wide section or the appropriate VirtualHost:

    AllowEncodedSlashes On

   AND,
2. DON’T double-escape the parameter as above, but do use urlencode() or equivalent to change slashes to %2F, eg. in the view layer,

   <?php echo link_to(
       $employee->getTitle(),
       '/employee/bytitle?title='.
       urlencode($employee->getTitle())
   );  ?>

Additional Complication

Browsers may treat the encoded slash in the URL differently.

IE 7, 8 and Firefox 3, and Safari 3.2.1 on Windows display the URL in the address bar with the %2F intact, as you’d expect.

In Google Chrome 1.0.154.43, the links work but the address bar displays a slash instead of the encoded %2F, so if you hit the “Go” button you get a 404 error. Weird. Bug submitted!