it does seem silly that the server would even try to serve those files
rather than check if they are of a certain header/mime before, but at least
with this method it does mean that you can "fix" your code to always bypass
this, and if your purposlly testing through the CLI-server anyway, changing
your code to "work" isnt that much a problem (imo)

Hi Ralph,

I'm aware of the ability to use a routing script to determine which files
to
serve via a "return false;".

My concern is that every framework / application etc is going to need one
in
order to work with the built-in server (even if they all need the same
one!)..

So considering this functionality is required by most (if not all) front
controller based applications and frameworks, and considering the router
script is really only useful for front controller based applications and
frameworks, why is this not the default behavior?

It seems silly to make use of the built-in server rely on more boilerplate
code than we already have in our apps!

Maybe this just feels weird because its PHP, rather than an apache/nginx
config file ..

I'm probably still be missing something though :)

Thanks,
Kiall

On Mon, Jul 11, 2011 at 3:15 PM, Ralph Schindler <ralph@smashlabs.com

wrote:

Hey Kiall,

An optional argument to the built in web server can be a php based
router.
If the router returns false, it will attempt to return the resource
as-it-is on disk.

Your command line looks like this:

php -S localhost:8000 -t ./path/to/docroot routing.php

routing.php can be one of two things- either a drop in replacement for
.htaccess or your sites index.php.

My routing.php looks like this:

<?php

// OR if (preg_match('/.(?:png|jpg|**jpeg|gif)$/',
$_SERVER["REQUEST_URI"]))
if (file_exists(DIR . '/' . $_SERVER['REQUEST_URI'])) {
return false; // serve the requested resource as-is.
} else {
include_once 'index.php';
}

If you choose to put your index.php in as the router, then your index.php
should be cli-server aware:

<?php

if (php_sapi_name() == 'cli-server') {
/* route static assets and return false */
}

/* go on with normal index.php operations */

I like the former approach as the routing.php can go inside your version
control ignore list and won't get checked in as part of the project.

To me, that is as many lines of Apache rewrite that one would have had
and
it is as feature complete as Apache rewrite.

-ralph

Hiya,

I've been playing with the built-in server, and have some concerns over
how
static assets are handled.

Currently, to run an application on the built-in server, we essentially
need
to list out all the static assets that should be served directly from
disk.
This is the opposite of what I believe the most common web server
configurations use.

I believe the built-in server should mimic typical configurations,
rather
than requiring applications to write code solely for PHP's web server.

Have I just missed something? or if not, what do people think of how
static
files are handled currently?

A typical Apache config extract (IMHO):

Turn on URL rewriting

RewriteEngine On
RewriteBase /

Allow any files or directories that exist to be displayed directly

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

Rewrite all other URLs to index.php/URL

RewriteRule .* index.php/$0 [PT]

Apologies is this has been brought up before, I've not seen any
discussion
of this topic so far.

Thanks,
Kiall