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)
On Mon, Jul 11, 2011 at 3:39 PM, Kiall Mac Innes <ki...@managedit.ie> wrote:
> 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 <ra...@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
> >
> >
> >
> > On 7/11/11 6:46 AM, Kiall Mac Innes wrote:
> >
> >> 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
> >>
> >>
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
