Why must need mod_rewrite
yugi
Since habari has only one entry point and use a dispatch to handle it.
I think if modify class Control and URL , support host which have not
mod_rewrite is not hard.
Can fix this or there are some questions why not support this.
Thanks for your great habari, I'm trying read source code and also
help translate it to Simple-Chinese, I'm a Chinese colleage student.
Chris J. Davis
The rewrite we use ensures that all requests are sent to index.php
for processing. I am not sure how we would accomplish this without
some sort of rewrite system in place. Any thoughts on the subject
would be welcome.
And thanks for helping out with the translation!
yugi
First I'll look into habari's rewrite system and think
about how to do this.
Currently habari(Version 0.6.2) has not release language zh-CN,
and I don't know wheather anyone is doing the thing.
If I finish translating and checking it, I'll share it.
rick c
Habari's translations are handled on Launchpad. You can see them all
at https://translations.launchpad.net/habari/trunk/+pots/habari . The
one for zh-CN says it is fairly complete.
Rick
Sean Coates
>
> First I'll look into habari's rewrite system and think
> about how to do this.
It _could_ be done with uglier URLs and some hackery in the code:
With mod_rewrite:
http://blog.example.com/path/to/habari/foo-bar
Could become without mod_rewrite:
http://blog.example.com/path/to/habari/index.php/foo-bar
S
Realpolitik
mod_rewrite, but could easily be done in in a plugin provided
redirects were taken care of
$start_url = Plugins::filter('rewrite_request', $start_url);
$buffer = Plugins::filter('final_output', $buffer);
For redirects, there should probably be a filter for rewriting URLS
public static function redirect( $url = '', $continue = false )
yugi
Realpolitik <cav...@gmail.com> wrote:
> This would be useful for the many shared hosts that don't allow
> mod_rewrite, but could easily be done in in a plugin provided
> redirects were taken care of
>
> $start_url = Plugins::filter('rewrite_request', $start_url);
>
> $buffer = Plugins::filter('final_output', $buffer);
>
> For redirects, there should probably be a filter for rewriting URLS
>
> public static function redirect( $url = '', $continue = false )
yugi
write a plugin(a little difficult).
Follow is what i try to do, it's ok but not full tested.
<1> modify index.php add code like:
if( ! defined( 'HAS_MOD_REWRITE' ) ) {
define( 'HAS_MOD_REWRITE', true );
}
>> if you have no mod_rewrite you can define:
define( 'HAS_MOD_REWRITE', false );
<2> modify Controller::parse_request()
>> modify code::
/* Trim off any leading or trailing slashes */
$start_url = trim($start_url, '/');
/* 3 line code ADD BY ME */
if ( HAS_MOD_REWRITE === FALSE ) {
$start_url = str_replace('index.php/', '', $start_url);
}
/* Allow plugins to rewrite the stub before it's passed through
the rules */
/* Grab the URL filtering rules from DB */
$matched_rule = URL::parse($controller->stub);
>> My purpose is to hide "index.php" so it's same when you has
mod_rewrite and not affect current plugin which hooks
'rewrite_request',
because I remove 'index.php' in variable $start_url, but
$controller->stub
has no 'index.php' and that's why I should modify Utils::redirect
and
URL::get(URL::out call it).
<3> URL::get
if ( $selectedrule instanceOf RewriteRule ) {
$return_url = $selectedrule->build( $args, $useall, $noamp );
/* 3 line code ADD BY ME */
if ( HAS_MOD_REWRITE === FALSE ) {
$return_url = 'index.php/' . $return_url;
}
if ( $prepend_site ) {
return Site::get_url( 'habari', true ) . $return_url;
}
else {
return $return_url;
}
}
<4> Utils::redirect
if ( $url == '' ) {
$url = Controller::get_full_url() . (isset($_SERVER
['QUERY_STRING']) ? '?' . $_SERVER['QUERY_STRING'] : '');
/* 3 line code ADD BY ME, very ugly */
if ( HAS_MOD_REWRITE === FALSE ) {
$url = Controller::get_base_url() . 'index.php/' .
Controller::get_stub() . (isset($_SERVER['QUERY_STRING']) ? '?' .
$_SERVER['QUERY_STRING'] : ''); //FIXME:yugi
}
}
header('Location: ' . $url, true, 302);
if (!$continue) exit;
}
Now it may work, but in Site::get_url(Site::out_url call it) failed.
But in theme file like loginform.php has code like
<a href="<?php Site::out_url( 'habari' ); ?>/user/logout">
I think write code like follow is better
<a href="<?php URL::out( 'user', array( 'page' => 'logout' ) ); ?
>">
Site::out_url( 'habari' ) should use for static file.
Site::out_url( 'admin' ) also has same problem, so I modify
Site::get_url
>> code::
case 'admin':
//$url = Site::get_url( 'habari' ) . '/admin';
$url = Site::get_url( 'habari' ) . '/index.php/admin'; //ADD
BY ME
If write a plugin I think it should add some more hooks.
Currently it works but not full tested, sorry for my bad English.
yugi
Owen Winkler
> anyone?
What follows is entirely my own opinion and my reaction based on that
opinion.
Hosts that supply mod_rewrite are no more expensive than hosts that
don't -- it's generally not a feature that you pay more for.
Habari relies heavily on the front controller pattern that is most
reliably implemented on Apache (at the moment) using mod_rewrite for
implementation.
We typically require hosts that have features enabled that others might
not, such as PHP5 and PDO. I would not expect to see a case where those
features are enabled but mod_rewrite is not.
Providing an additional method to implement rewrites in Habari sounds
nice, but added features also incur added development costs. These
additional features, however unlikely, could also introduce security
concerns, which are especially tricky given that all of the core
developers I am aware of use mod_rewrite and are unlikely to use an
alternative rewrite mechanism in wide testing.
Given the ubiquity of mod_rewrite at hosts that offer it for no
additional cost, and the added maintenance for alternatives to this
primary and well-established method of implementing a Front Controller
Pattern in Apache, I'm personally inclined to ignore most speculation
about it unless I see someone contribute superior quality, complete,
security-hardened code that implements it.
Unless the email that introduces it offers it in such a way that it's
extremely compelling to pursue, I'm afraid I just don't have the
personal inclination to do anything about it. I suppose that someone
could provide a compelling argument for anything, but I would be
surprised if one existed for this.
Owen
Realpolitik
> concerns, which are especially tricky given that all of the core
> developers I am aware of use mod_rewrite and are unlikely to use an
> alternative rewrite mechanism in wide testing.
> Given the ubiquity of mod_rewrite at hosts that offer it for no
> additional cost, and the added maintenance for alternatives to this
> primary and well-established method of implementing a Front Controller
> Pattern in Apache
directly is refreshing for developers, but leads to a smaller
marketshare. If you've got a crappy host, you're not likely to change
hosts just to get Habari. Additionally, if you've got a host who
doesn't have mod_rewrite enabled by default but has something where
you can request that it be enabled, you're also less likely to try
Habari because its a pain in the ass to request it, wait 2-3 days, and
then install a the software. Why do that when you could pick one of
the many other blog softwares that give you instant access?
I'm not advocating supporting endless legacy systems but there should
be more than one degree of freedom within Habari's setup. I disagree
with the claim that adding a system that uses index.php/foo/bar or
index.php?foo=1&bar=2 poses a serious security risk because such
access would only be permitted on the 2% of Habari installations
without mod_rewrite and once the system is implemented and done so
securely, the likelihood of breaking that system without creating a
similar issue in the mod_rewrite implementation would be very low.
Yes, this does hinge on getting it right to begin with.
I've really just been playing devil's advocate, however, I don't think
it's necessary. This functionality is better added via a plugin, which
requires more hooks - and I do support adding them.
yugi
> I've really just been playing devil's advocate, however, I don't think
> it's necessary. This functionality is better added via a plugin, which
> requires more hooks - and I do support adding them.
This not affects core version and give an alternative choice
when without mod_rewrite.
Owen Winkler
>
> I've really just been playing devil's advocate, however, I don't think
> it's necessary. This functionality is better added via a plugin, which
> requires more hooks - and I do support adding them.
Adding hooks that are not exclusively useful for enabling
non-mod_rewrite URLs is a much more compelling development task.
Owen
Arthus Erea
Realpolitik
> non-mod_rewrite URLs is a much more compelling development task.
the Apache + mod_rewrite subset is.
eighty4
There's simple solutions for it for both Nginx and Lighttp on the
wiki.
Caius Durling
Hash: SHA1
On 15 Jun 2009, at 11:15, eighty4 wrote:
> It should be noted that Habari does work without mod_rewrite.
> There's simple solutions for it for both Nginx and Lighttp on the
> wiki.
I think the OP meant without any rewrite solution in the webserver,
rather than just using nginx or lighttpd's rewrite functionality to
use habari. :)
C
- ---
Caius Durling
ca...@caius.name
+44 (0) 7960 268 100
http://caius.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAko2IIQACgkQlj5WkEOM/Ni9+gCgzf5+MAioz0EMpSyd4/2V9jIC
S34AoIHwsPjAsruItHmtH4w7HRSO0LS9
=nuUZ
-----END PGP SIGNATURE-----
Realpolitik
> There's simple solutions for it for both Nginx and Lighttp on the
> wiki.
the web server marketshare =D. There are tools that are mod_rewrite
compatible even for IIS, but it seems like users on Drupal (http://
drupal.org/node/470868) have been finding trouble with this and as
with all other MS related products it's pay-for-play (http://
www.micronovae.com/ModRewrite/Purchase.html).
This will not make/break Habari's future, but it is something that
helps determine the extent of it's future influence, and considering
it wouldn't take very long to implement, is something that should be
given more consideration than it currently is. Lets pretend a very
generous 75% of Habari's potential user base has the ability to
rewrite URLs, it could have 33% more reach.
Caius Durling
Hash: SHA1
On 15 Jun 2009, at 14:47, Realpolitik wrote:
> This will not make/break Habari's future, but it is something that
> helps determine the extent of it's future influence, and considering
> it wouldn't take very long to implement, is something that should be
> given more consideration than it currently is. Lets pretend a very
> generous 75% of Habari's potential user base has the ability to
> rewrite URLs, it could have 33% more reach.
How many PHP 4 hosts are there out there still? Should we support them
too because it'll let more people use habari?
Not trying to be awkward intentionally, but we've got to draw the line
somewhere, and mod_rewrite seems like a valid requirement to me. I
don't think I've ever had a host where I either didn't have it, or
couldn't get it enabled. And most of those I have experience with were
cheap £20-50/year hosts, when you get power users that build their own
webservers it becomes a non-issue too.
And you've always got the chicken and egg problem don't forget, if
more software that the average user will use requires something that's
basically a non-issue for a host to provide, then more hosts will
provide that something out the box (or give you the option to ask for
it.)
C
- ---
Caius Durling
ca...@caius.name
+44 (0) 7960 268 100
http://caius.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAko2UpoACgkQlj5WkEOM/NjPMQCfUYfn9yajnfxfsPs6xGSsyD7J
EcQAoMPfrTRQ8Ta7wkGhBvjXI/A0YVgy
=rH6h
-----END PGP SIGNATURE-----
Rich Bowen
On Jun 15, 2009, at 09:47, Realpolitik wrote:
> Lets pretend a very
> generous 75% of Habari's potential user base has the ability to
> rewrite URLs, it could have 33% more reach.
I love making decisions based on made-up statistics. It's one of the
things I love so much about my day job.</sarcasm>
On my side of the fence, I'm fighting this battle with education. The
only reason that folks *don't* have mod_rewrite enabled is ignorance,
in which vacuum folks made up security myths and pretend that they're
doing it for reasons of security and/or performance.
If you have sysadmins who refuse to enable mod_rewrite for reasons
that seem spurious, please feel free to give them my phone number. I'd
be glad to talk with them about their concerns, and help them
eliminate those concerns.
In this age, mod_rewrite is an essential part of the Apache Web
Server, and folks that have it disabled are crippling their customers.
This is a pretty simple business decision. Enable mod_rewrite, or
folks will eventually move to a provider that will. Unfortunately,
there's an ENORMOUS amount of misinformation out there about
mod_rewrite, and a lot of ignorant people pushing "tips and tricks"
that are misleading or just plain wrong. On the Apache documentation
project, we've been actively fighting this for about three years. And
some of the improvements in Apache 2.4 make entire classes of rewrite
rules unnecessary.
And I'm still holding on to the hope that https://issues.apache.org/bugzilla/show_bug.cgi?id=47184
will get implemented, and this issue will go away - at least for
folks that move to Apache 2.4.
--
Whatever you do will be insignificant, but it is very important that
you do it.
Mahatma Ghandi
Owen Winkler
>
> This will not make/break Habari's future, but it is something that
> helps determine the extent of it's future influence, and considering
> it wouldn't take very long to implement, is something that should be
> given more consideration than it currently is. Lets pretend a very
> generous 75% of Habari's potential user base has the ability to
> rewrite URLs, it could have 33% more reach.
Perhaps. But while an underlying goal of Habari may be to extend its
reach, it's not at the expense of introducing legacy/throwback
technology. We specified PHP5 early on for that reason, and at the time
that was seen as a detriment to Habari's reach also.
I suspect that the GoPHP5 initiative, where developers simply cut off
their own support of PHP4, had a lot to do with PHP5 acceptance across
hosts. I would prefer to be driving change, rather than holding onto
legacy for the sake of bigger installation counts.
I can think of no practical reason - not reach-related - to avoid
requiring mod_rewrite.
Owen
Realpolitik
> On Jun 15, 2009, at 09:47, Realpolitik wrote:
>
> > Lets pretend a very
> > generous 75% of Habari's potential user base has the ability to
> > rewrite URLs, it could have 33% more reach.
>
> I love making decisions based on made-up statistics. It's one of the
> things I love so much about my day job.</sarcasm>
28.35% iis
2.69% ngnix
0.99% lighttp
78.52% total (ignoring QQ - 12.25%, Google - 3.68%, Sun < 1%, and
others)
50.17% mod_rewrite compatible (max)
Assuming: 100% of apache servers have mod_rewrite
Assuming: all ngnix and lighttp servers are compatible
63.9% of end-user webservers can run Habari
Definitely less than 100% of Apache servers are using mod_rewrite, but
I didn't want to fight about specific data so I said lets be generous
to people who disagree with me and say that 75% of end-user webservers
can run Habari. I also didn't want to do the math.
Sean Coates
This is totally irrelevant unless we have core developers who use,
develop, maintain and deploy Habari in non-mod_rewrite environments
and who are willing to do the work to stay on top of this.
This is precisely why PHP has traditionally had poor support for
Windows and why the shared hosting implementations haven't been so
good: the core developers care more about big systems running some
flavour of unix.
S
Realpolitik
anyone to add in hooks to allow for plugin-support for non mod_rewrite
installations. I like to question other people's reasoning, especially
when I disagree, but I do not feel strongly one way or the other about
this topic. I think it's unfortunate there isn't support for
mod_rewriteless systems, but this topic is wasting too much time to be
worthwhile for me and I feel like I keep getting dragged in to defend
something that I would never use.
I feel like anyone reading from here on out should know that what is
being asked for by yugi and Arthus (and supported by me) is the
implementation of one or two hooks that enable a mod_rewriteless
plugin. This is no longer a discussion about whether to include native
support for non mod_rewrite servers into Habari.
On Jun 15, 4:20 pm, Sean Coates <s...@caedmon.net> wrote:
> This is totally irrelevant unless we have core developers who use,
> develop, maintain and deploy Habari in non-mod_rewrite environments
> and who are willing to do the work to stay on top of this.
feature, but it would not be true if it's solely an add-on because
there are many simple ways to do this - ways that, once written
properly, are unlikely to break without a complete change in the
underlying structure. It should take an hour or two to develop and
test, you're right. But once you have a script that just uses
something as ugly as index.php/<the habari generated URL> you could
leave it alone without fear of breaking until there are major rewrites
to the plugin / Controller system. There are other ways to do this,
including splitting the request into values ?a&b&c, sending ?/a/b/c,
sending an encrypted URL index.php?a=3ddbe56389. In terms of long
term development costs, any issues that arise with new releases /
changesets should be visible after a 20 minute test session with the
url_rewriteless plugin.
On Jun 15, 10:23 am, Owen Winkler <epit...@gmail.com> wrote:
> Perhaps. But while an underlying goal of Habari may be to extend its
> reach, it's not at the expense of introducing legacy/throwback
> technology. We specified PHP5 early on for that reason, and at the time
> that was seen as a detriment to Habari's reach also.
>
> I suspect that the GoPHP5 initiative, where developers simply cut off
> their own support of PHP4, had a lot to do with PHP5 acceptance across
> hosts. I would prefer to be driving change, rather than holding onto
> legacy for the sake of bigger installation counts.
I've only read ~20% of the Habari code at this point and only have a
good understanding of about 10% of it (meaning I've played around with
it directly, or toyed with creating a plugin/theme that did so). From
what I've seen it would require many changes to legacy (but still
functioning) methods instead of the updated methods used and object
workarounds - whether it be their loading, definition, or interaction
in order to achieve the same functionality. Providing PHP4 support in
a product that uses many PHP5 only features is a huge undertaking that
could not reasonably be done in a plugin and would in turn produce
numerous errors not just for those who use PHP4 but also those who use
PHP5. In addition, the performance would suffer because those
workarounds would be cumbersome.
A simple fix to support up-to-date active servers like ISS and Sun or
Apache with users who do not have or do not want to use mod_rewrite is
a much smaller "project" and should take a few hours at most. The
errors would be self contained, and even if the developer(s) only use
the mod-rewrite for developing the mod_rewriteless plugin, any users
who experience issues could create a ticket, and that developer could
easily switch back to mod_writeless to reproduce the error and fix
it.
If you want to take on a cause, take on the "say no to IE" cause and
just stop developing IE6 compatible website (I'd like that =D). The
supporting lack of mod_rewrite is not supporting legacy code, and not
using mod_rewrite is not an "old" style of web development. It's core
Apache functionality that is employed by nine out of the top ten
websites in the world based on traffic (though several of them do use
mod_rewrite for a subset of features).
Excluding a plugin that would allow people to create mod_rewriteless
functionality for Habari is not championing a cause, and you will
affect nothing by it except a loss in users. If apache 2.4 comes out
and doesn't allow the characters ? or & to perform their functions and
instead forces everyone to split their variables up by /, then I would
say you shouldn't support the old method of accessing URLs and sending
GET variables because then you really would be affecting a change. As
it is, you're not pushing people towards the future, you're just
pushing people towards a different method -- when the alternate method
isn't used by IIS and other webservers, and when the alternate method
will exist for the next twenty years.
> I can think of no practical reason - not reach-related - to avoid
> requiring mod_rewrite.
The only practical reason that isn't reach related would be if using a
non mod_rewrite version was faster, more reliable, and more secure. I
have not heard any convincing arguments that not using mod_rewrite
would increase performance in all three realms. The conversation has
always about reach and "ease of use" which harkens back to reach.
It's simple to do, hurts no one, and provides lots of potential
benefit. Let the plugins sort out how they want to do it.
eighty4
hooks in my previous post. I vote for adding hooks. Imho hooks cant
hurt. Someone might even figure out some more fun stuff to do with
those hooks. I for instance wrote Asciify using hooks that probably
wasn't intended for doing exactly that and I know for a fact that no
core devs are sweds so they definitly don't test what the hooks
asciify uses does.
(Forgive my horrible english. Hopfully you get my reasoning anyway.)
Chris J. Davis
rewrite operation, especially if it is only a job of a couple of
hours. What someone needs to do, which is always the answer by the
way, is craft something and submit it as a patch. Once we have a patch
to test we can then see about getting it into trunk.
Speaking of patches, excuse me while I go and look through trac for
some stuff to commit...
Sean Coates
On 16-Jun-09, at 9:48 AM, Chris J. Davis wrote:
> I am not against the inclusion of hooks that would allow for non
> rewrite operation
To be clear, neither am I.
We'd just need someone who actually cares about such things to
maintain the plugins that use those hooks...
(and I shamefully haven't even updated my own plugins to the new API
yet)
S
Owen Winkler
>
> I feel like all of the comparisons to PHP4 are drastic overstatements.
That's because it's not about what would be required to support the
feature, but the philosophical choice of developing only certain avenues
explicitly to avoid the cost of others.
There were many contributing factors to the choice, but the reason we
did not include PHP4 support in Habari was not primarily because it
would required many man-hours of development to include in addition to
PHP5. We did not include PHP4 support because we wanted to be more on
the forefront of development, and excluding the technology we didn't
want allowed us to focus more on what we did want.
mod_rewrite is not legacy, but in the similar vein that PHP4 does not
support OOP well, non-mod_rewrite servers do not support the front
controller pattern that we preferred. So rather than developing with
the intent to support code we didn't want and would never use, we chose
to rely on rewritten URLs.
It's not a matter of comparative simplicity in development. It's a
choice to have the core do something only one way, the way we wanted, well.
I'm belaboring this discussion not because I particularly care about
mod_rewrite, but I think that understanding the motives of early-on
Habari development decisions is generally important for figuring out
what features and direction Habari takes in the future.
>
> Excluding a plugin that would allow people to create mod_rewriteless
> functionality for Habari is not championing a cause, and you will
> affect nothing by it except a loss in users.
The only person suggesting the exclusion of such plugins is you. Please
review the thread, where even I said that including the hooks would be fine.
The problem you face is that I doubt any core developers will care to
write this code for you. And since none that I know of use
non-rewritten URLs, it may also be difficult for them to test submitted
patches. Nonetheless, there are already core devs replying to the
thread that are supportive of a patch, including myself, especially if
the hooks are useful for more than just avoiding mod_rewrite.
The energy put into this thread long ago exceeded writing the actual
code to implement its ideas.
Owen
Arthus Erea
implementing the hooks. These hooks could be tested even on rewritten
installs.
The plugin is best built and maintained by someone who does not use
mod_rewrite, and will thus have a vested interest in keeping it up to
date.
Finally, some notes on the "debate" of mod_rewrite:
People frequently cited web server statistics, but that's not the
important part. The statistic we should be looking at is what
percentage of servers which meet all our other requirements (PHP5,
PDO, etc.) don't have mod_rewrite: I'm guessing it's much lower than
50%.
When looking at support of technology, we want to be sure it will not
hold the project back in any way. Supporting PHP4 would have done
that, since then we couldn't use the beficial aspects of PHP5. I
remain convinced adding hooks that could potentially support
mod_rewrite won't do anything to hold the project back. We can still
have all the front controller goodness, and most systems will be able
to support almost everything we do with mod_rewrite anyways.