You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Riccardo Cohen <r....@realty-property.com> on 2013/02/05 21:32:31 UTC
[users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Hello
I'm new to apache mailing list, sorry if I'm not 100% clear, and sorry
for this long description.
I have developped a website with php/mysql :
http://www.perspectives-musicales.org and placed it on a good hosting
service (web4all.fr).
To improve search engine rank I decided to set all urls to
/index.php/... and rewrite them to avoid having index.php in url (sort
of MVC technique combined with SEO...)
Example : the catalog is at url :
http://www.perspectives-musicales.org/en/all-albums
This should be transparantly mapped to
http://www.perspectives-musicales.org/index.php/en/all-albums thanks to
the rewrite rule :
RewriteRule ^en/(.*) ./index.php/en/$1
My application uses then $_SERVER["PATH_INFO"] (and not
$_SERVER["QUERY_STRING"]) to retreive url information. This worked
perfectly until last month, because web4all.fr changed the whole system
and separated apache from php, using fast cgi instead of mod_php.
The system is supposed to be more reliable and more efficient like this,
and apparently is. But the rewrite rule does not work anymore. So I
investigated and made some test :
I have a small test.php that displays the path_info and query_string.
You can presently test it here :
http://perspectives-musicales.org/test1/a/b/c
http://perspectives-musicales.org/test2/a/b/c
http://perspectives-musicales.org/test3/a/b/c
http://perspectives-musicales.org/test4/a/b/c
and I set the following rules :
RewriteRule ^test1/(.*) ./test.php/$1
RewriteRule ^test2/(.*) ./test.php?$1
RewriteRule ^test3/(.*) ./test.php?/$1
RewriteRule ^test4/(.*) http://www.perspectives-musicales.org/test.php/$1
None of these 4 rewrite rules are convenient. Here is why :
- test1 : the system anwsers 404 "No input file specified". I think (not
sure) that Apache beleives that test.php is a folder, and cannot find it
so answers 404
- test2 : the rewrite rule works, but of course the url information is
no more in path_info, it is in query_string as shown in the page content
- test3 : same as test2
- test4 : almost good, I can have the url info in path_info, but apache
begins first with a 302 redirection and then changes the url to
http://www.perspectives-musicales.org/test.php/a/b/c, which looses all
search engine efficiency (and also eventual POST variables if any).
My host tried several searches on forums including this one, and could
not find any answer. It seems to be an apache bug, but not sure, I have
no bug number to give anyway. If it is a bug, it is demontrated by test1
I think.
So here is my question : Is there any way to make this rewrite rule work
in fastcgi mode, and what is the syntax for it, to keep info in
path_info without 302 redirection. The Apache version is 2.2.23 and
mod_fcgid is version 2.3.7 with configuration flag cgi.fix_pathinfo=1
If there is a way, thanks for your help I'd be glad to test it. If no
could you explain why and how to solve it. As workaround we used test4
syntax in the whole site, to make it work, but it is bad for search
engine, and creates problem in backoffice (because certain backoffice
functions use POST variables)
I know I can change my code to use query_string everywhere instead of
path_info, but if I can avoid changing and testing all my websites it
would be really great
Thanks a lot for your anwser.
--
Riccardo Cohen
+33 (0)6 09 83 64 49
Société Realty-Property.com
1 rue de la Monnaie
37000 Tours
France
<http://www.appartement-maison.fr>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Hendrik Schmieder <he...@jedox.com>.
Riccardo Cohen schrieb:
> On 07/02/13 16:50, Yehuda Katz wrote:
>> On Tue, Feb 5, 2013 at 3:32 PM, Riccardo Cohen
>> <r.cohen@realty-property.com <ma...@realty-property.com>> wrote:
>>
>> Example : the catalog is at url :
>> http://www.perspectives-__musicales.org/en/all-albums
>> <http://www.perspectives-musicales.org/en/all-albums>
>> This should be transparantly mapped to
>> http://www.perspectives-__musicales.org/index.php/en/__all-albums
>> <http://www.perspectives-musicales.org/index.php/en/all-albums>
>> thanks to the rewrite rule :
>>
>> RewriteRule ^en/(.*) ./index.php/en/$1
>>
>> My application uses then $_SERVER["PATH_INFO"] (and not
>> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
>> perfectly until last month, because web4all.fr <http://web4all.fr>
>> changed the whole system and separated apache from php, using fast
>> cgi instead of mod_php.
>>
>> -------------
>>
>> RewriteRule ^test2/(.*) ./test.php?$1
>> - test2 : the rewrite rule works, but of course the url information
>> is no more in path_info, it is in query_string as shown in the page
>> content
>>
>> My host tried several searches on forums including this one, and
>> could not find any answer. It seems to be an apache bug, but not
>> sure, I have no bug number to give anyway. If it is a bug, it is
>> demontrated by test1 I think.
>>
>> Probably not an HTTPD bug. More likely a problem with the PHP fcgi
>> configuration.
>>
>> I know I can change my code to use query_string everywhere instead
>> of path_info, but if I can avoid changing and testing all my
>> websites it would be really great
>>
>> This is the most reliable option. I use something like this:
>> RewriteRule ^en/(.*) ./index.php?page=en/$1
>>
>>
>> - Y
>
> Thanks for your answer Yehuda
>
> Your rewrite rule will behave like my test2/3, converting pathinfo to a
> querystring... and force me to change and double check all my website !
>
> Thanks anyway.
>
You have to check your php code anyway, since the content of $_SERVER in
case of mod_php differs from the content of $_SERVER in case of mod_fcgid.
Hendrik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Riccardo Cohen <r....@realty-property.com>.
Thanks for your answer Yehuda
Your rewrite rule will behave like my test2/3, converting pathinfo to a
querystring... and force me to change and double check all my website !
Thanks anyway.
On 07/02/13 16:50, Yehuda Katz wrote:
> On Tue, Feb 5, 2013 at 3:32 PM, Riccardo Cohen
> <r.cohen@realty-property.com <ma...@realty-property.com>> wrote:
>
> Example : the catalog is at url :
> http://www.perspectives-__musicales.org/en/all-albums
> <http://www.perspectives-musicales.org/en/all-albums>
> This should be transparantly mapped to
> http://www.perspectives-__musicales.org/index.php/en/__all-albums
> <http://www.perspectives-musicales.org/index.php/en/all-albums>
> thanks to the rewrite rule :
>
> RewriteRule ^en/(.*) ./index.php/en/$1
>
> My application uses then $_SERVER["PATH_INFO"] (and not
> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
> perfectly until last month, because web4all.fr <http://web4all.fr>
> changed the whole system and separated apache from php, using fast
> cgi instead of mod_php.
>
> -------------
>
> RewriteRule ^test2/(.*) ./test.php?$1
> - test2 : the rewrite rule works, but of course the url information
> is no more in path_info, it is in query_string as shown in the page
> content
>
> My host tried several searches on forums including this one, and
> could not find any answer. It seems to be an apache bug, but not
> sure, I have no bug number to give anyway. If it is a bug, it is
> demontrated by test1 I think.
>
> Probably not an HTTPD bug. More likely a problem with the PHP fcgi
> configuration.
>
> I know I can change my code to use query_string everywhere instead
> of path_info, but if I can avoid changing and testing all my
> websites it would be really great
>
> This is the most reliable option. I use something like this:
> RewriteRule ^en/(.*) ./index.php?page=en/$1
>
>
> - Y
--
Riccardo Cohen
+33 (0)6 09 83 64 49
Société Realty-Property.com
1 rue de la Monnaie
37000 Tours
France
<http://www.appartement-maison.fr>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Yehuda Katz <ye...@ymkatz.net>.
On Tue, Feb 5, 2013 at 3:32 PM, Riccardo Cohen
<r....@realty-property.com>wrote:
> Example : the catalog is at url : http://www.perspectives-**
> musicales.org/en/all-albums<http://www.perspectives-musicales.org/en/all-albums>
> This should be transparantly mapped to http://www.perspectives-**
> musicales.org/index.php/en/**all-albums<http://www.perspectives-musicales.org/index.php/en/all-albums>thanks to the rewrite rule :
>
> RewriteRule ^en/(.*) ./index.php/en/$1
>
> My application uses then $_SERVER["PATH_INFO"] (and not
> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
> perfectly until last month, because web4all.fr changed the whole system
> and separated apache from php, using fast cgi instead of mod_php.
>
-------------
> RewriteRule ^test2/(.*) ./test.php?$1
> - test2 : the rewrite rule works, but of course the url information is no
> more in path_info, it is in query_string as shown in the page content
>
> My host tried several searches on forums including this one, and could not
> find any answer. It seems to be an apache bug, but not sure, I have no bug
> number to give anyway. If it is a bug, it is demontrated by test1 I think.
Probably not an HTTPD bug. More likely a problem with the PHP fcgi
configuration.
> I know I can change my code to use query_string everywhere instead of
> path_info, but if I can avoid changing and testing all my websites it would
> be really great
>
This is the most reliable option. I use something like this:
RewriteRule ^en/(.*) ./index.php?page=en/$1
- Y
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Ben Johnson <be...@indietorrent.org>.
On 2/14/2013 11:52 AM, Benoit GEORGELIN (web4all) wrote:
> Hi !
>
> I'm agree with you BEN.
> Thanks for all these information.
>
> I'll try some others tests with Riccardo and we will update the message even if it's not an apache problem :)
A follow-up / solution would be great, should one be found. Better to
have it documented on an off-topic list than not at all! :)
You and Riccardo may wish to have a look at this article, if you haven't
already:
http://stackoverflow.com/questions/279966/php-self-vs-path-info-vs-script-name-vs-request-uri
It explains the differences between PHP_SELF vs PATH_INFO vs SCRIPT_NAME
vs REQUEST_URI and underscores the same advice that I've offered in the
way of a workaround (using the QUERY_STRING).
The bottom line seems to be that PATH_INFO is not well-implemented
everywhere.
Best of luck,
-Ben
>
> Thanks
>
> On 2/13/2013 10:49 PM, Benoit GEORGELIN (web4all) wrote:
>>
>> Hi guys,
>>
>> here is the content of perspectives-musicales.org's wrapper:
>>
>>
>> #!/bin/sh
>> # Wrapper PHP w4a
>> PHPRC="/opt/datas_prod/http1/confs/phpini/perspectives-musicales.org.ini"
>> PHP_FCGI_MAX_REQUESTS=8000
>> export PHPRC
>> export PHP_FCGI_MAX_REQUESTS
>> exec /opt/w4abin/php/5.2/bin/php-cgi
>> # Généré par IWAL 20130212-22:02:11
>
> Thanks for posting this, Benoit. The wrapper script looks fine to me.
> So, the problem must be elsewhere.
>
> As I stated previously, the string that is printed when the 404 request
> is returned is peculiar; it looks to be coming from PHP, not Apache.
> Here's the evidence:
>
> # grep -ir "No input file specified" /etc
> Binary file /etc/alternatives/php-cgi matches
> Binary file /etc/alternatives/php-cgi-bin matches
>
> Searching the Web for 'php-cgi "No input file specified"' yields some
> interesting results:
>
>>From http://www.php.net/manual/en/security.cgi-bin.php#60508 :
>
>
> ---------------------------------------------------------------------
> "One of the most common reasons why you get 'No input file specified'
> (AKA 'the second most useful error message in the world') is that you
> have set 'doc_root' (in php.ini) to a value which is [different from]
> the 'DocumentRoot' defined in the apache configuration.
>
> This is the same for other webservers. For example, on lighttpd, make
> sure the 'server.document-root' value is the same as what is defined as
> 'doc_root' in php.ini."
> ---------------------------------------------------------------------
>
>
> Given this remark, does the value for "doc_root" in
> "perspectives-musicales.org.ini" match the value for Apache's effective
> "DocumentRoot" (which is customer-specific, presumably, perhaps via
> VirtualHost)?
>
>>From http://community.activestate.com/faq/cgi-debugging-no-input-fi :
>
>
> ---------------------------------------------------------------------
> Question:
>
> When I try to debug PHP using CGI Emulation, I get this error:
>
> No input file specified.
>
> Answer:
>
> This is because your PHP CGI interpreter has been compiled with
> cgi.force_redirect set to on for security reasons. We can fix this in
> Komodo by changing this setting in the copy of php.ini that Komodo uses:
>
> - open the php.ini copy that Komodo is using:
>
> ~/.komodo/host-<hostname>/php/<php-version>/php.ini
>
> - change the setting:
>
> ; cgi.force_redirect = 1
>
> to
>
> cgi.force_redirect = 0
> ---------------------------------------------------------------------
>
>
> To what value is cgi.force_redirect set in "perspectives-musicales.org.ini"?
>
>>From http://jenseng.com/archives/000035.html :
>
>
> ---------------------------------------------------------------------
> When running PHP as a CGI binary on Apache, you might get the above
> error if you request a nonexistent PHP file.
>
> [...]
>
> The reason this happens is that any requests ending in .php are simply
> handed off to the PHP executable without verifying that such a file
> exists. Although this is by design, it can be a bit offputting.
> Unfortunately, there does not appear to be a way to configure the PHP
> executable to return a "normal" 404 to Apache if the requested script
> does not exist. *True, it does return a 404 response header along with
> the "No input file specified"*, but it won't return the appropriate
> ErrorDocument under any circumstances.
> ---------------------------------------------------------------------
>
>
> While it's possible to "fix" the 404 issue so that a "prettier" message
> is displayed, the root cause here seems to be, very simply, that the PHP
> CGI executable can't find the requested PHP file (test.php, in this
> case). I'm not sure what would cause this, but I'd start with the leads
> that I posted above.
>
> This is shaping-up to a problem with the PHP configuration, though, not
> Apache or mod_rewrite.
>
> Cheers,
>
> -Ben
>
>>> This may be for the reasons outlined in the article that I cited above.
>>> i f you'd like to post your CGI wrapper script, I'd be happy to take a
>>> look. Alas, you may lack access to this script, in which case, it's a
>>> moot point. Although, I must say, it seems unlikely that your host would
>>> have misconfigured the wrapper script. (Then again, we've all seen worse.)
>>
>> If you need more technical information, let me know .
>> I'll appreciate to solve this issue and understand from where the problem is coming
>>
>>
>> Regards,
>>
>> Benoît Georgelin
>> Web 4 all Hébergeur associatif
>>
>>
>>
>
> Cordialement,
>
> Benoît Georgelin
> Web 4 all Hébergeur associatif
> +1 514 458 0890
> benoit.georgelin@web 4 all.fr
>
> Afin de contribuer au respect de l'environnement, merci de n'imprimer ce mail qu'en cas de nécessité
>
> ----- Mail original -----
>> De: "Ben Johnson" <be...@indietorrent.org>
>> À: users@httpd.apache.org
>> Envoyé: Mercredi 13 Février 2013 22:15:40
>> Objet: Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
>>
>>
>>
>> On 2/13/2013 4:14 PM, Riccardo Cohen wrote:
>>> Hi Ben
>>>
>>>>> I tried without the dot : RewriteRule ^en/(.*) index.php/en/$1 but it
>>>>> gave also an error 404.
>>>>
>>>> It would be helpful to know what, exactly, appears in Apache's access
>>>> log (and/or error log, if you can manage to find that, too) in each of
>>>> these test cases.
>>>
>>> I've asked for the apache error log, and found no error in it.
>>> Only one which was a request done before adding the new .htaccess, but
>>> nothing else :
>>>
>>> [Tue Feb 12 21:04:17 2013] [error] [client 90.24.101.9] File does not
>>> exist: /datas/vol1/w4a125552/var/www/perspectives-musicales.org/test6
>>
>> Very good. No problems there.
>>
>>>
>>> The access log show all requests normally with no particular message :
>>>
>>> 90.24.101.9 - - [12/Feb/2013:21:04:46 +0100] "GET /test1/a/b/c HTTP/1.1"
>>> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>>> Firefox/18.0" "20130212210446"
>>>
>>> 90.24.101.9 - - [12/Feb/2013:21:04:51 +0100] "GET /test2/a/b/c HTTP/1.1"
>>> 200 52 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>>> Firefox/18.0" "20130212210451"
>>>
>>> 90.24.101.9 - - [12/Feb/2013:21:04:56 +0100] "GET /test4/a/b/c HTTP/1.1"
>>> 302 206 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>>> Firefox/18.0" "20130212210456"
>>>
>>> 90.24.101.9 - - [12/Feb/2013:21:03:28 +0100] "GET /test5/a/b/c HTTP/1.1"
>>> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>>> Firefox/18.0" "20130212210328"
>>>
>>> 90.24.101.9 - - [12/Feb/2013:21:04:17 +0100] "GET /test6/a/b/c HTTP/1.1"
>>> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>>> Firefox/18.0" "20130212210417"
>>
>> This seems to imply that Apache is not generating the 404 errors; if it
>> were, one would expect access log entries to that effect.
>>
>>>
>>>>
>>>>> These are all my tests : (available at
>>>>> http://www.perspectives-musicales.org/test1/a/b/c etc.)
>>>>>
>>>>> RewriteRule ^test1/(.*) ./test.php/$1
>>>>> # = error 404
>>>>
>>>> I hit this URL and from what I can tell, the 404 response header is
>>>> coming from PHP, not Apache. The output is "No input file specified."
>>>> This doesn't look like a "stock" Apache 404 response. Did you build
>>>> logic into test.php that emits a 404 response header and this message
>>>> when some parameter is absent from the URL?
>>>
>>> test.php is only this :
>>>
>>> ok test
>>> <br>
>>> <?
>>> $info=$_SERVER["PATH_INFO"];
>>> echo "INFO=".$info."<br>";
>>> $query=$_SERVER["QUERY_STRING"];
>>> echo "query=".$query."<br>";
>>> ?>
>>>
>>> maybe the error comes from mod_fcgid itself ?
>>
>> Quite possibly. In fact, a search for "mod_fcgid No input file
>> specified" yields the following article:
>>
>> http://isp-control.net/forum/printthread.php?tid=12653
>>
>> Of particular import is the suggestion, "Okay, this may be caused by
>> either (1) apache sending an incorrect path to the php file to php5-cgi;
>> or (2) something (permissions?) that prevents php5-cgi from running the
>> script."
>>
>> Do other PHP scripts function as expected when executed via mod_fcgid?
>> Or do they all return the error string, "No input file specified" and a
>> 404 response?
>>
>>>>
>>>>> RewriteRule ^test2/(.*) ./test.php?$1
>>>>> # = parameters are in query_string instead of path_info
>>>>
>>>> Why is this a problem?
>>>
>>> My whole web application is developped with urls like
>>>
>>> http://www.perspectives-musicales.org/en/all-associations
>>>
>>> for search engine optimizations, where "en" and "all-associations" are
>>> not pages or directories, but program arguments (replacing
>>> "?lang=en&command=all-associations" which are poor seo)
>>
>> Right; I built a PHP framework that uses so-called "clean-URLs", and am
>> well-versed in the theory behind this approach, as well as its
>> execution. The rationale seems sound.
>>
>>> So, as explained in my first email, all arguments to my application
>>> controller are in $_SERVER["PATH_INFO"] (and not
>>> $_SERVER["QUERY_STRING"]). And that did work like a charm with
>>> mod_php... Changing all my application with data in query_string is not
>>> very complicated if I wrote a good program ( :) ) but will need a lot of
>>> checks.
>>>
>>> Actually at the point where I am now, i've already spent some time on it...
>>
>> My PHP framework functions the same way via mod_php as it does with
>> mod_fcgid and mod_fastcgi. I achieved this by using a well-known
>> technique to rewrite the URLs (I place these directives into the
>> site-root's .htaccess file):
>>
>> <IfModule mod_rewrite.c>
>> RewriteEngine on
>> Options All
>>
>> # Modify the RewriteBase if you are using a subdirectory and the
>> # rewrite rules are not working properly:
>> # WARNING: Do not include a trailing slash on this directive if you
>> # include a path other than /!
>> #RewriteBase /
>>
>> # Rewrite URIs of the form 'index.php?q=x' (except for real
>> # files/directories):
>> RewriteCond %{REQUEST_FILENAME} !-f
>> RewriteCond %{REQUEST_FILENAME} !-d
>>
>> RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
>> </IfModule>
>>
>> (WordPress, Joomla, and many other frameworks do something similar.)
>>
>> Then, in PHP, $_GET['q'] will always contain the "clean URL" (unless, of
>> course, the 'q' value is overwritten, e.g., the URL contains
>> "?q=something-else"). For this reason, you may wish to use something
>> other than "q" in the RewriteRule value. You can then parse the
>> clean-URL to obtain its "individual segments" and do with them as you
>> will. While over simplified, an example is to call explode('/',
>> trim($_GET['q'], '/')) in PHP. This will return an array that contains
>> the various "path segments". The URL
>> http://www.perspectives-musicales.org/en/all-associations would return
>>
>> array (size=2)
>> 0 => string 'en' (length=2)
>> 1 => string 'all-associations' (length=16)
>>
>> Granted, undertaking this approach would mean rewriting certain aspects
>> of your application, but chances are that you'll thank yourself later.
>> You'll have a much more portable application that is
>> scripting-language-agnostic, with respect to URL structure. (Switching
>> to another scripting language requires a simple change to your
>> RewriteRule only.)
>>
>>>>
>>>> It should be stated that mod_php and mod_fcgid populate these values in
>>>> different ways. From what I understand, PATH_INFO is less reliable and
>>>> less well-implemented than QUERY_STRING. Fundamentally, this is why you
>>>> are observing different behavior/values here after moving from mod_php
>>>> to mod_fcgid.
>>>
>>> I'm not sure that this is a problem with the PATH_INFO variable since
>>> the error occurs even before php has any chance to start executing (the
>>> test.php is not executed at all in test1)
>>
>> This may be for the reasons outlined in the article that I cited above.
>> If you'd like to post your CGI wrapper script, I'd be happy to take a
>> look. Alas, you may lack access to this script, in which case, it's a
>> moot point. Although, I must say, it seems unlikely that your host would
>> have misconfigured the wrapper script. (Then again, we've all seen worse.)
>>
>>>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>>>> # = parameters are in query_string instead of path_info
>>>>
>>>> Same as above.
>>>>
>>>>> RewriteRule ^test4/(.*)
>>>>> http://www.perspectives-musicales.org/test.php/$1
>>>>> # = redirection 302
>>>>
>>>> I don't see a 302 response for this one. I see the same 404 and message
>>>> as above. Maybe you changed something after sending this message.
>>>
>>> I use firefox http live header and it shows a status code 302 ("HTTP/1.1
>>> 302 Found") then the browser redirect to the page as if it was another
>>> website
>>
>> You're right; I checked this again, and I do see the 302 redirect. I
>> think it was a matter of enabling the "Persist" feature in Firebug.
>> (Otherwise, the "Net" panel is refreshed after the redirect is sent.)
>> Thanks for double-checking your work here!
>>
>>> I still think that [apache or mod_fcgid] cannot execute test.php in
>>> test1 just because it thinks it is a directory and cannot find it.
>>
>> That may very well be. And the solution I offered above should address
>> that shortcoming.
>>
>> I can't tell you exactly why it doesn't work (only a VPS with shell
>> access would make that possible), but I can tell you what *does* work.
>>
>> I'm happy to answer any questions.
>>
>> Good luck!
>>
>> -Ben
>>
>>>
>>>>
>>>>> RewriteRule ^test5/(.*) test.php/$1
>>>>> # = error 404
>>>>>
>>>>> RewriteRule ^test6/(.*) /test.php/$1
>>>>> # = error 404
>>>>
>>>> Same as the others with 404 responses.
>>>>
>>>>>
>>>>>
>>>>> Thanks for your help.
>>>>
>>>> You're welcome. I'll wait to hear back before offering additional
>>>> information.
>>>>
>>>> -Ben
>>>>
>>>>>
>>>>>
>>>>> On 12/02/13 19:40, Ben Johnson wrote:
>>>>>>
>>>>>>
>>>>>> On 2/12/2013 10:59 AM, Riccardo Cohen wrote:
>>>>>>> Thanks Ben, here are the answers :
>>>>>>>
>>>>>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>>>>>
>>>>>>> in .htaccess
>>>>>>>
>>>>>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>>>>>
>>>>>>> no change with or without
>>>>>>>
>>>>>>>> 3.) Have you reviewed Apache's access log at all?
>>>>>>>
>>>>>>> I'll have a look now
>>>>>>>
>>>>>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly
>>>>>>>> what
>>>>>>>> the mod_rewrite engine is doing?
>>>>>>>
>>>>>>> I'll try that. Is it possible to set it in .htacces or must I change
>>>>>>> global apache configuration (I only have access to my .htaccess in
>>>>>>> this
>>>>>>> hosting).
>>>>>>
>>>>>> Unfortunately, RewriteLogLevel can be set in the "server config" and
>>>>>> "virtual host" contexts only. (You can make this type of determination
>>>>>> in the future by visiting the manual page and looking for the "context"
>>>>>> value:
>>>>>> http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewriteloglevel .)
>>>>>>
>>>>>>
>>>>>> This is one of many reasons for which hosting on a VPS over which you
>>>>>> have complete control is beneficial.
>>>>>>
>>>>>> In any case, we'll have to proceed without access to the rewrite log.
>>>>>>
>>>>>> Is there a specific reason for which you're using "./index.php" in the
>>>>>> right-hand side of the rule? I'm referring to the period ("."), in
>>>>>> particular. This may well be the source of the problem. It could be
>>>>>> that
>>>>>> mod_php interprets that relative path (./index.php) "correctly",
>>>>>> whereas
>>>>>> mod_fcgid does not.
>>>>>>
>>>>>> Try this:
>>>>>>
>>>>>> RewriteRule ^en/(.*) index.php/en/$1
>>>>>>
>>>>>> -Ben
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> On 12/02/13 14:53, Ben Johnson wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2/12/2013 2:16 AM, Riccardo Cohen wrote:
>>>>>>>>> Hello
>>>>>>>>> I received some clues from this list members, thanks for that. But
>>>>>>>>> unfortunately my problem is not solved.
>>>>>>>>>
>>>>>>>>> It's not that I want others to focus on me, but I'm quite sure that
>>>>>>>>> there is a real problem (if not why would it work perfectly on
>>>>>>>>> mod_php
>>>>>>>>> ?), I could not find any solution googling about it (even with the
>>>>>>>>> help
>>>>>>>>> of the host technical team), and I would like a confirmation that 1)
>>>>>>>>> it's not an error from my understanding, and 2) there is no
>>>>>>>>> workaround
>>>>>>>>> for it.
>>>>>>>>
>>>>>>>> I doubt it is a problem with the software. mod_rewrite has been put
>>>>>>>> through the paces over the years and I'd be shocked if a bug were
>>>>>>>> uncovered given your rule's relative simplicity.
>>>>>>>>
>>>>>>>> Before digesting your post in its entirety, I have a couple of
>>>>>>>> questions
>>>>>>>> first.
>>>>>>>>
>>>>>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>>>>>>
>>>>>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>>>>>>
>>>>>>>> 3.) Have you reviewed Apache's access log at all?
>>>>>>>>
>>>>>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly
>>>>>>>> what
>>>>>>>> the mod_rewrite engine is doing?
>>>>>>>>
>>>>>>>> -Ben
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> So I'll be very pleased to here from some qualified developer
>>>>>>>>> before I
>>>>>>>>> spend 2 days to modify and retest all my application.
>>>>>>>>>
>>>>>>>>> Thanks in advance.
>>>>>>>>>
>>>>>>>>> On 07/02/13 11:17, Riccardo Cohen wrote:
>>>>>>>>>> Sorry to insist but I'm really blocked and I really need help.
>>>>>>>>>> Here is a small summary for those who don't want to read all :
>>>>>>>>>>
>>>>>>>>>> I want to make a rewrite from :
>>>>>>>>>>
>>>>>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>>>>>> to
>>>>>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>>>>>
>>>>>>>>>> my rewrite rule is
>>>>>>>>>>
>>>>>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>>>>>
>>>>>>>>>> This works when apache is runnnig with mod_php, but not when
>>>>>>>>>> running
>>>>>>>>>> mod_fcgid (php as cgi). In cgi mode I have a 404 error.
>>>>>>>>>>
>>>>>>>>>> The Apache version is 2.2.23 and mod_fcgid is version 2.3.7 with
>>>>>>>>>> configuration flag cgi.fix_pathinfo=1
>>>>>>>>>>
>>>>>>>>>> Thanks for your help.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 05/02/13 21:32, Riccardo Cohen wrote:
>>>>>>>>>>> Hello
>>>>>>>>>>> I'm new to apache mailing list, sorry if I'm not 100% clear, and
>>>>>>>>>>> sorry
>>>>>>>>>>> for this long description.
>>>>>>>>>>>
>>>>>>>>>>> I have developped a website with php/mysql :
>>>>>>>>>>> http://www.perspectives-musicales.org and placed it on a good
>>>>>>>>>>> hosting
>>>>>>>>>>> service (web4all.fr).
>>>>>>>>>>> To improve search engine rank I decided to set all urls to
>>>>>>>>>>> /index.php/... and rewrite them to avoid having index.php in url
>>>>>>>>>>> (sort
>>>>>>>>>>> of MVC technique combined with SEO...)
>>>>>>>>>>>
>>>>>>>>>>> Example : the catalog is at url :
>>>>>>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>>>>>>> This should be transparantly mapped to
>>>>>>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>>>>>> thanks to
>>>>>>>>>>> the rewrite rule :
>>>>>>>>>>>
>>>>>>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>>>>>>
>>>>>>>>>>> My application uses then $_SERVER["PATH_INFO"] (and not
>>>>>>>>>>> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
>>>>>>>>>>> perfectly until last month, because web4all.fr changed the whole
>>>>>>>>>>> system
>>>>>>>>>>> and separated apache from php, using fast cgi instead of mod_php.
>>>>>>>>>>>
>>>>>>>>>>> The system is supposed to be more reliable and more efficient like
>>>>>>>>>>> this,
>>>>>>>>>>> and apparently is. But the rewrite rule does not work anymore.
>>>>>>>>>>> So I
>>>>>>>>>>> investigated and made some test :
>>>>>>>>>>>
>>>>>>>>>>> I have a small test.php that displays the path_info and
>>>>>>>>>>> query_string.
>>>>>>>>>>> You can presently test it here :
>>>>>>>>>>>
>>>>>>>>>>> http://perspectives-musicales.org/test1/a/b/c
>>>>>>>>>>> http://perspectives-musicales.org/test2/a/b/c
>>>>>>>>>>> http://perspectives-musicales.org/test3/a/b/c
>>>>>>>>>>> http://perspectives-musicales.org/test4/a/b/c
>>>>>>>>>>>
>>>>>>>>>>> and I set the following rules :
>>>>>>>>>>>
>>>>>>>>>>> RewriteRule ^test1/(.*) ./test.php/$1
>>>>>>>>>>> RewriteRule ^test2/(.*) ./test.php?$1
>>>>>>>>>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>>>>>>>>>> RewriteRule ^test4/(.*)
>>>>>>>>>>> http://www.perspectives-musicales.org/test.php/$1
>>>>>>>>>>>
>>>>>>>>>>> None of these 4 rewrite rules are convenient. Here is why :
>>>>>>>>>>>
>>>>>>>>>>> - test1 : the system anwsers 404 "No input file specified". I
>>>>>>>>>>> think
>>>>>>>>>>> (not
>>>>>>>>>>> sure) that Apache beleives that test.php is a folder, and cannot
>>>>>>>>>>> find it
>>>>>>>>>>> so answers 404
>>>>>>>>>>>
>>>>>>>>>>> - test2 : the rewrite rule works, but of course the url
>>>>>>>>>>> information is
>>>>>>>>>>> no more in path_info, it is in query_string as shown in the page
>>>>>>>>>>> content
>>>>>>>>>>>
>>>>>>>>>>> - test3 : same as test2
>>>>>>>>>>>
>>>>>>>>>>> - test4 : almost good, I can have the url info in path_info, but
>>>>>>>>>>> apache
>>>>>>>>>>> begins first with a 302 redirection and then changes the url to
>>>>>>>>>>> http://www.perspectives-musicales.org/test.php/a/b/c, which
>>>>>>>>>>> looses all
>>>>>>>>>>> search engine efficiency (and also eventual POST variables if
>>>>>>>>>>> any).
>>>>>>>>>>>
>>>>>>>>>>> My host tried several searches on forums including this one, and
>>>>>>>>>>> could
>>>>>>>>>>> not find any answer. It seems to be an apache bug, but not sure, I
>>>>>>>>>>> have
>>>>>>>>>>> no bug number to give anyway. If it is a bug, it is demontrated by
>>>>>>>>>>> test1
>>>>>>>>>>> I think.
>>>>>>>>>>>
>>>>>>>>>>> So here is my question : Is there any way to make this rewrite
>>>>>>>>>>> rule
>>>>>>>>>>> work
>>>>>>>>>>> in fastcgi mode, and what is the syntax for it, to keep info in
>>>>>>>>>>> path_info without 302 redirection. The Apache version is
>>>>>>>>>>> 2.2.23 and
>>>>>>>>>>> mod_fcgid is version 2.3.7 with configuration flag
>>>>>>>>>>> cgi.fix_pathinfo=1
>>>>>>>>>>>
>>>>>>>>>>> If there is a way, thanks for your help I'd be glad to test it.
>>>>>>>>>>> If no
>>>>>>>>>>> could you explain why and how to solve it. As workaround we used
>>>>>>>>>>> test4
>>>>>>>>>>> syntax in the whole site, to make it work, but it is bad for
>>>>>>>>>>> search
>>>>>>>>>>> engine, and creates problem in backoffice (because certain
>>>>>>>>>>> backoffice
>>>>>>>>>>> functions use POST variables)
>>>>>>>>>>>
>>>>>>>>>>> I know I can change my code to use query_string everywhere
>>>>>>>>>>> instead of
>>>>>>>>>>> path_info, but if I can avoid changing and testing all my
>>>>>>>>>>> websites it
>>>>>>>>>>> would be really great
>>>>>>>>>>>
>>>>>>>>>>> Thanks a lot for your anwser.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>>>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite
problem
Posted by "Benoit GEORGELIN (web4all)" <be...@web4all.fr>.
Hi !
I'm agree with you BEN.
Thanks for all these information.
I'll try some others tests with Riccardo and we will update the message even if it's not an apache problem :)
Thanks
On 2/13/2013 10:49 PM, Benoit GEORGELIN (web4all) wrote:
>
> Hi guys,
>
> here is the content of perspectives-musicales.org's wrapper:
>
>
> #!/bin/sh
> # Wrapper PHP w4a
> PHPRC="/opt/datas_prod/http1/confs/phpini/perspectives-musicales.org.ini"
> PHP_FCGI_MAX_REQUESTS=8000
> export PHPRC
> export PHP_FCGI_MAX_REQUESTS
> exec /opt/w4abin/php/5.2/bin/php-cgi
> # Généré par IWAL 20130212-22:02:11
Thanks for posting this, Benoit. The wrapper script looks fine to me.
So, the problem must be elsewhere.
As I stated previously, the string that is printed when the 404 request
is returned is peculiar; it looks to be coming from PHP, not Apache.
Here's the evidence:
# grep -ir "No input file specified" /etc
Binary file /etc/alternatives/php-cgi matches
Binary file /etc/alternatives/php-cgi-bin matches
Searching the Web for 'php-cgi "No input file specified"' yields some
interesting results:
>From http://www.php.net/manual/en/security.cgi-bin.php#60508 :
---------------------------------------------------------------------
"One of the most common reasons why you get 'No input file specified'
(AKA 'the second most useful error message in the world') is that you
have set 'doc_root' (in php.ini) to a value which is [different from]
the 'DocumentRoot' defined in the apache configuration.
This is the same for other webservers. For example, on lighttpd, make
sure the 'server.document-root' value is the same as what is defined as
'doc_root' in php.ini."
---------------------------------------------------------------------
Given this remark, does the value for "doc_root" in
"perspectives-musicales.org.ini" match the value for Apache's effective
"DocumentRoot" (which is customer-specific, presumably, perhaps via
VirtualHost)?
>From http://community.activestate.com/faq/cgi-debugging-no-input-fi :
---------------------------------------------------------------------
Question:
When I try to debug PHP using CGI Emulation, I get this error:
No input file specified.
Answer:
This is because your PHP CGI interpreter has been compiled with
cgi.force_redirect set to on for security reasons. We can fix this in
Komodo by changing this setting in the copy of php.ini that Komodo uses:
- open the php.ini copy that Komodo is using:
~/.komodo/host-<hostname>/php/<php-version>/php.ini
- change the setting:
; cgi.force_redirect = 1
to
cgi.force_redirect = 0
---------------------------------------------------------------------
To what value is cgi.force_redirect set in "perspectives-musicales.org.ini"?
>From http://jenseng.com/archives/000035.html :
---------------------------------------------------------------------
When running PHP as a CGI binary on Apache, you might get the above
error if you request a nonexistent PHP file.
[...]
The reason this happens is that any requests ending in .php are simply
handed off to the PHP executable without verifying that such a file
exists. Although this is by design, it can be a bit offputting.
Unfortunately, there does not appear to be a way to configure the PHP
executable to return a "normal" 404 to Apache if the requested script
does not exist. *True, it does return a 404 response header along with
the "No input file specified"*, but it won't return the appropriate
ErrorDocument under any circumstances.
---------------------------------------------------------------------
While it's possible to "fix" the 404 issue so that a "prettier" message
is displayed, the root cause here seems to be, very simply, that the PHP
CGI executable can't find the requested PHP file (test.php, in this
case). I'm not sure what would cause this, but I'd start with the leads
that I posted above.
This is shaping-up to a problem with the PHP configuration, though, not
Apache or mod_rewrite.
Cheers,
-Ben
>> This may be for the reasons outlined in the article that I cited above.
>> i f you'd like to post your CGI wrapper script, I'd be happy to take a
>> look. Alas, you may lack access to this script, in which case, it's a
>> moot point. Although, I must say, it seems unlikely that your host would
>> have misconfigured the wrapper script. (Then again, we've all seen worse.)
>
> If you need more technical information, let me know .
> I'll appreciate to solve this issue and understand from where the problem is coming
>
>
> Regards,
>
> Benoît Georgelin
> Web 4 all Hébergeur associatif
>
>
>
Cordialement,
Benoît Georgelin
Web 4 all Hébergeur associatif
+1 514 458 0890
benoit.georgelin@web 4 all.fr
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce mail qu'en cas de nécessité
----- Mail original -----
> De: "Ben Johnson" <be...@indietorrent.org>
> À: users@httpd.apache.org
> Envoyé: Mercredi 13 Février 2013 22:15:40
> Objet: Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
>
>
>
> On 2/13/2013 4:14 PM, Riccardo Cohen wrote:
>> Hi Ben
>>
>>>> I tried without the dot : RewriteRule ^en/(.*) index.php/en/$1 but it
>>>> gave also an error 404.
>>>
>>> It would be helpful to know what, exactly, appears in Apache's access
>>> log (and/or error log, if you can manage to find that, too) in each of
>>> these test cases.
>>
>> I've asked for the apache error log, and found no error in it.
>> Only one which was a request done before adding the new .htaccess, but
>> nothing else :
>>
>> [Tue Feb 12 21:04:17 2013] [error] [client 90.24.101.9] File does not
>> exist: /datas/vol1/w4a125552/var/www/perspectives-musicales.org/test6
>
> Very good. No problems there.
>
>>
>> The access log show all requests normally with no particular message :
>>
>> 90.24.101.9 - - [12/Feb/2013:21:04:46 +0100] "GET /test1/a/b/c HTTP/1.1"
>> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>> Firefox/18.0" "20130212210446"
>>
>> 90.24.101.9 - - [12/Feb/2013:21:04:51 +0100] "GET /test2/a/b/c HTTP/1.1"
>> 200 52 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>> Firefox/18.0" "20130212210451"
>>
>> 90.24.101.9 - - [12/Feb/2013:21:04:56 +0100] "GET /test4/a/b/c HTTP/1.1"
>> 302 206 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>> Firefox/18.0" "20130212210456"
>>
>> 90.24.101.9 - - [12/Feb/2013:21:03:28 +0100] "GET /test5/a/b/c HTTP/1.1"
>> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>> Firefox/18.0" "20130212210328"
>>
>> 90.24.101.9 - - [12/Feb/2013:21:04:17 +0100] "GET /test6/a/b/c HTTP/1.1"
>> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>> Firefox/18.0" "20130212210417"
>
> This seems to imply that Apache is not generating the 404 errors; if it
> were, one would expect access log entries to that effect.
>
>>
>>>
>>>> These are all my tests : (available at
>>>> http://www.perspectives-musicales.org/test1/a/b/c etc.)
>>>>
>>>> RewriteRule ^test1/(.*) ./test.php/$1
>>>> # = error 404
>>>
>>> I hit this URL and from what I can tell, the 404 response header is
>>> coming from PHP, not Apache. The output is "No input file specified."
>>> This doesn't look like a "stock" Apache 404 response. Did you build
>>> logic into test.php that emits a 404 response header and this message
>>> when some parameter is absent from the URL?
>>
>> test.php is only this :
>>
>> ok test
>> <br>
>> <?
>> $info=$_SERVER["PATH_INFO"];
>> echo "INFO=".$info."<br>";
>> $query=$_SERVER["QUERY_STRING"];
>> echo "query=".$query."<br>";
>> ?>
>>
>> maybe the error comes from mod_fcgid itself ?
>
> Quite possibly. In fact, a search for "mod_fcgid No input file
> specified" yields the following article:
>
> http://isp-control.net/forum/printthread.php?tid=12653
>
> Of particular import is the suggestion, "Okay, this may be caused by
> either (1) apache sending an incorrect path to the php file to php5-cgi;
> or (2) something (permissions?) that prevents php5-cgi from running the
> script."
>
> Do other PHP scripts function as expected when executed via mod_fcgid?
> Or do they all return the error string, "No input file specified" and a
> 404 response?
>
>>>
>>>> RewriteRule ^test2/(.*) ./test.php?$1
>>>> # = parameters are in query_string instead of path_info
>>>
>>> Why is this a problem?
>>
>> My whole web application is developped with urls like
>>
>> http://www.perspectives-musicales.org/en/all-associations
>>
>> for search engine optimizations, where "en" and "all-associations" are
>> not pages or directories, but program arguments (replacing
>> "?lang=en&command=all-associations" which are poor seo)
>
> Right; I built a PHP framework that uses so-called "clean-URLs", and am
> well-versed in the theory behind this approach, as well as its
> execution. The rationale seems sound.
>
>> So, as explained in my first email, all arguments to my application
>> controller are in $_SERVER["PATH_INFO"] (and not
>> $_SERVER["QUERY_STRING"]). And that did work like a charm with
>> mod_php... Changing all my application with data in query_string is not
>> very complicated if I wrote a good program ( :) ) but will need a lot of
>> checks.
>>
>> Actually at the point where I am now, i've already spent some time on it...
>
> My PHP framework functions the same way via mod_php as it does with
> mod_fcgid and mod_fastcgi. I achieved this by using a well-known
> technique to rewrite the URLs (I place these directives into the
> site-root's .htaccess file):
>
> <IfModule mod_rewrite.c>
> RewriteEngine on
> Options All
>
> # Modify the RewriteBase if you are using a subdirectory and the
> # rewrite rules are not working properly:
> # WARNING: Do not include a trailing slash on this directive if you
> # include a path other than /!
> #RewriteBase /
>
> # Rewrite URIs of the form 'index.php?q=x' (except for real
> # files/directories):
> RewriteCond %{REQUEST_FILENAME} !-f
> RewriteCond %{REQUEST_FILENAME} !-d
>
> RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
> </IfModule>
>
> (WordPress, Joomla, and many other frameworks do something similar.)
>
> Then, in PHP, $_GET['q'] will always contain the "clean URL" (unless, of
> course, the 'q' value is overwritten, e.g., the URL contains
> "?q=something-else"). For this reason, you may wish to use something
> other than "q" in the RewriteRule value. You can then parse the
> clean-URL to obtain its "individual segments" and do with them as you
> will. While over simplified, an example is to call explode('/',
> trim($_GET['q'], '/')) in PHP. This will return an array that contains
> the various "path segments". The URL
> http://www.perspectives-musicales.org/en/all-associations would return
>
> array (size=2)
> 0 => string 'en' (length=2)
> 1 => string 'all-associations' (length=16)
>
> Granted, undertaking this approach would mean rewriting certain aspects
> of your application, but chances are that you'll thank yourself later.
> You'll have a much more portable application that is
> scripting-language-agnostic, with respect to URL structure. (Switching
> to another scripting language requires a simple change to your
> RewriteRule only.)
>
>>>
>>> It should be stated that mod_php and mod_fcgid populate these values in
>>> different ways. From what I understand, PATH_INFO is less reliable and
>>> less well-implemented than QUERY_STRING. Fundamentally, this is why you
>>> are observing different behavior/values here after moving from mod_php
>>> to mod_fcgid.
>>
>> I'm not sure that this is a problem with the PATH_INFO variable since
>> the error occurs even before php has any chance to start executing (the
>> test.php is not executed at all in test1)
>
> This may be for the reasons outlined in the article that I cited above.
> If you'd like to post your CGI wrapper script, I'd be happy to take a
> look. Alas, you may lack access to this script, in which case, it's a
> moot point. Although, I must say, it seems unlikely that your host would
> have misconfigured the wrapper script. (Then again, we've all seen worse.)
>
>>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>>> # = parameters are in query_string instead of path_info
>>>
>>> Same as above.
>>>
>>>> RewriteRule ^test4/(.*)
>>>> http://www.perspectives-musicales.org/test.php/$1
>>>> # = redirection 302
>>>
>>> I don't see a 302 response for this one. I see the same 404 and message
>>> as above. Maybe you changed something after sending this message.
>>
>> I use firefox http live header and it shows a status code 302 ("HTTP/1.1
>> 302 Found") then the browser redirect to the page as if it was another
>> website
>
> You're right; I checked this again, and I do see the 302 redirect. I
> think it was a matter of enabling the "Persist" feature in Firebug.
> (Otherwise, the "Net" panel is refreshed after the redirect is sent.)
> Thanks for double-checking your work here!
>
>> I still think that [apache or mod_fcgid] cannot execute test.php in
>> test1 just because it thinks it is a directory and cannot find it.
>
> That may very well be. And the solution I offered above should address
> that shortcoming.
>
> I can't tell you exactly why it doesn't work (only a VPS with shell
> access would make that possible), but I can tell you what *does* work.
>
> I'm happy to answer any questions.
>
> Good luck!
>
> -Ben
>
>>
>>>
>>>> RewriteRule ^test5/(.*) test.php/$1
>>>> # = error 404
>>>>
>>>> RewriteRule ^test6/(.*) /test.php/$1
>>>> # = error 404
>>>
>>> Same as the others with 404 responses.
>>>
>>>>
>>>>
>>>> Thanks for your help.
>>>
>>> You're welcome. I'll wait to hear back before offering additional
>>> information.
>>>
>>> -Ben
>>>
>>>>
>>>>
>>>> On 12/02/13 19:40, Ben Johnson wrote:
>>>>>
>>>>>
>>>>> On 2/12/2013 10:59 AM, Riccardo Cohen wrote:
>>>>>> Thanks Ben, here are the answers :
>>>>>>
>>>>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>>>>
>>>>>> in .htaccess
>>>>>>
>>>>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>>>>
>>>>>> no change with or without
>>>>>>
>>>>>>> 3.) Have you reviewed Apache's access log at all?
>>>>>>
>>>>>> I'll have a look now
>>>>>>
>>>>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly
>>>>>>> what
>>>>>>> the mod_rewrite engine is doing?
>>>>>>
>>>>>> I'll try that. Is it possible to set it in .htacces or must I change
>>>>>> global apache configuration (I only have access to my .htaccess in
>>>>>> this
>>>>>> hosting).
>>>>>
>>>>> Unfortunately, RewriteLogLevel can be set in the "server config" and
>>>>> "virtual host" contexts only. (You can make this type of determination
>>>>> in the future by visiting the manual page and looking for the "context"
>>>>> value:
>>>>> http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewriteloglevel .)
>>>>>
>>>>>
>>>>> This is one of many reasons for which hosting on a VPS over which you
>>>>> have complete control is beneficial.
>>>>>
>>>>> In any case, we'll have to proceed without access to the rewrite log.
>>>>>
>>>>> Is there a specific reason for which you're using "./index.php" in the
>>>>> right-hand side of the rule? I'm referring to the period ("."), in
>>>>> particular. This may well be the source of the problem. It could be
>>>>> that
>>>>> mod_php interprets that relative path (./index.php) "correctly",
>>>>> whereas
>>>>> mod_fcgid does not.
>>>>>
>>>>> Try this:
>>>>>
>>>>> RewriteRule ^en/(.*) index.php/en/$1
>>>>>
>>>>> -Ben
>>>>>
>>>>>
>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> On 12/02/13 14:53, Ben Johnson wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2/12/2013 2:16 AM, Riccardo Cohen wrote:
>>>>>>>> Hello
>>>>>>>> I received some clues from this list members, thanks for that. But
>>>>>>>> unfortunately my problem is not solved.
>>>>>>>>
>>>>>>>> It's not that I want others to focus on me, but I'm quite sure that
>>>>>>>> there is a real problem (if not why would it work perfectly on
>>>>>>>> mod_php
>>>>>>>> ?), I could not find any solution googling about it (even with the
>>>>>>>> help
>>>>>>>> of the host technical team), and I would like a confirmation that 1)
>>>>>>>> it's not an error from my understanding, and 2) there is no
>>>>>>>> workaround
>>>>>>>> for it.
>>>>>>>
>>>>>>> I doubt it is a problem with the software. mod_rewrite has been put
>>>>>>> through the paces over the years and I'd be shocked if a bug were
>>>>>>> uncovered given your rule's relative simplicity.
>>>>>>>
>>>>>>> Before digesting your post in its entirety, I have a couple of
>>>>>>> questions
>>>>>>> first.
>>>>>>>
>>>>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>>>>>
>>>>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>>>>>
>>>>>>> 3.) Have you reviewed Apache's access log at all?
>>>>>>>
>>>>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly
>>>>>>> what
>>>>>>> the mod_rewrite engine is doing?
>>>>>>>
>>>>>>> -Ben
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> So I'll be very pleased to here from some qualified developer
>>>>>>>> before I
>>>>>>>> spend 2 days to modify and retest all my application.
>>>>>>>>
>>>>>>>> Thanks in advance.
>>>>>>>>
>>>>>>>> On 07/02/13 11:17, Riccardo Cohen wrote:
>>>>>>>>> Sorry to insist but I'm really blocked and I really need help.
>>>>>>>>> Here is a small summary for those who don't want to read all :
>>>>>>>>>
>>>>>>>>> I want to make a rewrite from :
>>>>>>>>>
>>>>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>>>>> to
>>>>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>>>>
>>>>>>>>> my rewrite rule is
>>>>>>>>>
>>>>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>>>>
>>>>>>>>> This works when apache is runnnig with mod_php, but not when
>>>>>>>>> running
>>>>>>>>> mod_fcgid (php as cgi). In cgi mode I have a 404 error.
>>>>>>>>>
>>>>>>>>> The Apache version is 2.2.23 and mod_fcgid is version 2.3.7 with
>>>>>>>>> configuration flag cgi.fix_pathinfo=1
>>>>>>>>>
>>>>>>>>> Thanks for your help.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 05/02/13 21:32, Riccardo Cohen wrote:
>>>>>>>>>> Hello
>>>>>>>>>> I'm new to apache mailing list, sorry if I'm not 100% clear, and
>>>>>>>>>> sorry
>>>>>>>>>> for this long description.
>>>>>>>>>>
>>>>>>>>>> I have developped a website with php/mysql :
>>>>>>>>>> http://www.perspectives-musicales.org and placed it on a good
>>>>>>>>>> hosting
>>>>>>>>>> service (web4all.fr).
>>>>>>>>>> To improve search engine rank I decided to set all urls to
>>>>>>>>>> /index.php/... and rewrite them to avoid having index.php in url
>>>>>>>>>> (sort
>>>>>>>>>> of MVC technique combined with SEO...)
>>>>>>>>>>
>>>>>>>>>> Example : the catalog is at url :
>>>>>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>>>>>> This should be transparantly mapped to
>>>>>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>>>>> thanks to
>>>>>>>>>> the rewrite rule :
>>>>>>>>>>
>>>>>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>>>>>
>>>>>>>>>> My application uses then $_SERVER["PATH_INFO"] (and not
>>>>>>>>>> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
>>>>>>>>>> perfectly until last month, because web4all.fr changed the whole
>>>>>>>>>> system
>>>>>>>>>> and separated apache from php, using fast cgi instead of mod_php.
>>>>>>>>>>
>>>>>>>>>> The system is supposed to be more reliable and more efficient like
>>>>>>>>>> this,
>>>>>>>>>> and apparently is. But the rewrite rule does not work anymore.
>>>>>>>>>> So I
>>>>>>>>>> investigated and made some test :
>>>>>>>>>>
>>>>>>>>>> I have a small test.php that displays the path_info and
>>>>>>>>>> query_string.
>>>>>>>>>> You can presently test it here :
>>>>>>>>>>
>>>>>>>>>> http://perspectives-musicales.org/test1/a/b/c
>>>>>>>>>> http://perspectives-musicales.org/test2/a/b/c
>>>>>>>>>> http://perspectives-musicales.org/test3/a/b/c
>>>>>>>>>> http://perspectives-musicales.org/test4/a/b/c
>>>>>>>>>>
>>>>>>>>>> and I set the following rules :
>>>>>>>>>>
>>>>>>>>>> RewriteRule ^test1/(.*) ./test.php/$1
>>>>>>>>>> RewriteRule ^test2/(.*) ./test.php?$1
>>>>>>>>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>>>>>>>>> RewriteRule ^test4/(.*)
>>>>>>>>>> http://www.perspectives-musicales.org/test.php/$1
>>>>>>>>>>
>>>>>>>>>> None of these 4 rewrite rules are convenient. Here is why :
>>>>>>>>>>
>>>>>>>>>> - test1 : the system anwsers 404 "No input file specified". I
>>>>>>>>>> think
>>>>>>>>>> (not
>>>>>>>>>> sure) that Apache beleives that test.php is a folder, and cannot
>>>>>>>>>> find it
>>>>>>>>>> so answers 404
>>>>>>>>>>
>>>>>>>>>> - test2 : the rewrite rule works, but of course the url
>>>>>>>>>> information is
>>>>>>>>>> no more in path_info, it is in query_string as shown in the page
>>>>>>>>>> content
>>>>>>>>>>
>>>>>>>>>> - test3 : same as test2
>>>>>>>>>>
>>>>>>>>>> - test4 : almost good, I can have the url info in path_info, but
>>>>>>>>>> apache
>>>>>>>>>> begins first with a 302 redirection and then changes the url to
>>>>>>>>>> http://www.perspectives-musicales.org/test.php/a/b/c, which
>>>>>>>>>> looses all
>>>>>>>>>> search engine efficiency (and also eventual POST variables if
>>>>>>>>>> any).
>>>>>>>>>>
>>>>>>>>>> My host tried several searches on forums including this one, and
>>>>>>>>>> could
>>>>>>>>>> not find any answer. It seems to be an apache bug, but not sure, I
>>>>>>>>>> have
>>>>>>>>>> no bug number to give anyway. If it is a bug, it is demontrated by
>>>>>>>>>> test1
>>>>>>>>>> I think.
>>>>>>>>>>
>>>>>>>>>> So here is my question : Is there any way to make this rewrite
>>>>>>>>>> rule
>>>>>>>>>> work
>>>>>>>>>> in fastcgi mode, and what is the syntax for it, to keep info in
>>>>>>>>>> path_info without 302 redirection. The Apache version is
>>>>>>>>>> 2.2.23 and
>>>>>>>>>> mod_fcgid is version 2.3.7 with configuration flag
>>>>>>>>>> cgi.fix_pathinfo=1
>>>>>>>>>>
>>>>>>>>>> If there is a way, thanks for your help I'd be glad to test it.
>>>>>>>>>> If no
>>>>>>>>>> could you explain why and how to solve it. As workaround we used
>>>>>>>>>> test4
>>>>>>>>>> syntax in the whole site, to make it work, but it is bad for
>>>>>>>>>> search
>>>>>>>>>> engine, and creates problem in backoffice (because certain
>>>>>>>>>> backoffice
>>>>>>>>>> functions use POST variables)
>>>>>>>>>>
>>>>>>>>>> I know I can change my code to use query_string everywhere
>>>>>>>>>> instead of
>>>>>>>>>> path_info, but if I can avoid changing and testing all my
>>>>>>>>>> websites it
>>>>>>>>>> would be really great
>>>>>>>>>>
>>>>>>>>>> Thanks a lot for your anwser.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Ben Johnson <be...@indietorrent.org>.
On 2/13/2013 10:49 PM, Benoit GEORGELIN (web4all) wrote:
>
> Hi guys,
>
> here is the content of perspectives-musicales.org's wrapper:
>
>
> #!/bin/sh
> # Wrapper PHP w4a
> PHPRC="/opt/datas_prod/http1/confs/phpini/perspectives-musicales.org.ini"
> PHP_FCGI_MAX_REQUESTS=8000
> export PHPRC
> export PHP_FCGI_MAX_REQUESTS
> exec /opt/w4abin/php/5.2/bin/php-cgi
> # Généré par IWAL 20130212-22:02:11
Thanks for posting this, Benoit. The wrapper script looks fine to me.
So, the problem must be elsewhere.
As I stated previously, the string that is printed when the 404 request
is returned is peculiar; it looks to be coming from PHP, not Apache.
Here's the evidence:
# grep -ir "No input file specified" /etc
Binary file /etc/alternatives/php-cgi matches
Binary file /etc/alternatives/php-cgi-bin matches
Searching the Web for 'php-cgi "No input file specified"' yields some
interesting results:
>From http://www.php.net/manual/en/security.cgi-bin.php#60508 :
---------------------------------------------------------------------
"One of the most common reasons why you get 'No input file specified'
(AKA 'the second most useful error message in the world') is that you
have set 'doc_root' (in php.ini) to a value which is [different from]
the 'DocumentRoot' defined in the apache configuration.
This is the same for other webservers. For example, on lighttpd, make
sure the 'server.document-root' value is the same as what is defined as
'doc_root' in php.ini."
---------------------------------------------------------------------
Given this remark, does the value for "doc_root" in
"perspectives-musicales.org.ini" match the value for Apache's effective
"DocumentRoot" (which is customer-specific, presumably, perhaps via
VirtualHost)?
>From http://community.activestate.com/faq/cgi-debugging-no-input-fi :
---------------------------------------------------------------------
Question:
When I try to debug PHP using CGI Emulation, I get this error:
No input file specified.
Answer:
This is because your PHP CGI interpreter has been compiled with
cgi.force_redirect set to on for security reasons. We can fix this in
Komodo by changing this setting in the copy of php.ini that Komodo uses:
- open the php.ini copy that Komodo is using:
~/.komodo/host-<hostname>/php/<php-version>/php.ini
- change the setting:
; cgi.force_redirect = 1
to
cgi.force_redirect = 0
---------------------------------------------------------------------
To what value is cgi.force_redirect set in "perspectives-musicales.org.ini"?
>From http://jenseng.com/archives/000035.html :
---------------------------------------------------------------------
When running PHP as a CGI binary on Apache, you might get the above
error if you request a nonexistent PHP file.
[...]
The reason this happens is that any requests ending in .php are simply
handed off to the PHP executable without verifying that such a file
exists. Although this is by design, it can be a bit offputting.
Unfortunately, there does not appear to be a way to configure the PHP
executable to return a "normal" 404 to Apache if the requested script
does not exist. *True, it does return a 404 response header along with
the "No input file specified"*, but it won't return the appropriate
ErrorDocument under any circumstances.
---------------------------------------------------------------------
While it's possible to "fix" the 404 issue so that a "prettier" message
is displayed, the root cause here seems to be, very simply, that the PHP
CGI executable can't find the requested PHP file (test.php, in this
case). I'm not sure what would cause this, but I'd start with the leads
that I posted above.
This is shaping-up to a problem with the PHP configuration, though, not
Apache or mod_rewrite.
Cheers,
-Ben
>> This may be for the reasons outlined in the article that I cited above.
>> i f you'd like to post your CGI wrapper script, I'd be happy to take a
>> look. Alas, you may lack access to this script, in which case, it's a
>> moot point. Although, I must say, it seems unlikely that your host would
>> have misconfigured the wrapper script. (Then again, we've all seen worse.)
>
> If you need more technical information, let me know .
> I'll appreciate to solve this issue and understand from where the problem is coming
>
>
> Regards,
>
> Benoît Georgelin
> Web 4 all Hébergeur associatif
>
>
> ----- Mail original -----
> De: "Ben Johnson" <be...@indietorrent.org>
> À: users@httpd.apache.org
> Envoyé: Mercredi 13 Février 2013 22:15:40
> Objet: Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
>
>
>
> On 2/13/2013 4:14 PM, Riccardo Cohen wrote:
>> Hi Ben
>>
>>>> I tried without the dot : RewriteRule ^en/(.*) index.php/en/$1 but it
>>>> gave also an error 404.
>>>
>>> It would be helpful to know what, exactly, appears in Apache's access
>>> log (and/or error log, if you can manage to find that, too) in each of
>>> these test cases.
>>
>> I've asked for the apache error log, and found no error in it.
>> Only one which was a request done before adding the new .htaccess, but
>> nothing else :
>>
>> [Tue Feb 12 21:04:17 2013] [error] [client 90.24.101.9] File does not
>> exist: /datas/vol1/w4a125552/var/www/perspectives-musicales.org/test6
>
> Very good. No problems there.
>
>>
>> The access log show all requests normally with no particular message :
>>
>> 90.24.101.9 - - [12/Feb/2013:21:04:46 +0100] "GET /test1/a/b/c HTTP/1.1"
>> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>> Firefox/18.0" "20130212210446"
>>
>> 90.24.101.9 - - [12/Feb/2013:21:04:51 +0100] "GET /test2/a/b/c HTTP/1.1"
>> 200 52 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>> Firefox/18.0" "20130212210451"
>>
>> 90.24.101.9 - - [12/Feb/2013:21:04:56 +0100] "GET /test4/a/b/c HTTP/1.1"
>> 302 206 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>> Firefox/18.0" "20130212210456"
>>
>> 90.24.101.9 - - [12/Feb/2013:21:03:28 +0100] "GET /test5/a/b/c HTTP/1.1"
>> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>> Firefox/18.0" "20130212210328"
>>
>> 90.24.101.9 - - [12/Feb/2013:21:04:17 +0100] "GET /test6/a/b/c HTTP/1.1"
>> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
>> Firefox/18.0" "20130212210417"
>
> This seems to imply that Apache is not generating the 404 errors; if it
> were, one would expect access log entries to that effect.
>
>>
>>>
>>>> These are all my tests : (available at
>>>> http://www.perspectives-musicales.org/test1/a/b/c etc.)
>>>>
>>>> RewriteRule ^test1/(.*) ./test.php/$1
>>>> # = error 404
>>>
>>> I hit this URL and from what I can tell, the 404 response header is
>>> coming from PHP, not Apache. The output is "No input file specified."
>>> This doesn't look like a "stock" Apache 404 response. Did you build
>>> logic into test.php that emits a 404 response header and this message
>>> when some parameter is absent from the URL?
>>
>> test.php is only this :
>>
>> ok test
>> <br>
>> <?
>> $info=$_SERVER["PATH_INFO"];
>> echo "INFO=".$info."<br>";
>> $query=$_SERVER["QUERY_STRING"];
>> echo "query=".$query."<br>";
>> ?>
>>
>> maybe the error comes from mod_fcgid itself ?
>
> Quite possibly. In fact, a search for "mod_fcgid No input file
> specified" yields the following article:
>
> http://isp-control.net/forum/printthread.php?tid=12653
>
> Of particular import is the suggestion, "Okay, this may be caused by
> either (1) apache sending an incorrect path to the php file to php5-cgi;
> or (2) something (permissions?) that prevents php5-cgi from running the
> script."
>
> Do other PHP scripts function as expected when executed via mod_fcgid?
> Or do they all return the error string, "No input file specified" and a
> 404 response?
>
>>>
>>>> RewriteRule ^test2/(.*) ./test.php?$1
>>>> # = parameters are in query_string instead of path_info
>>>
>>> Why is this a problem?
>>
>> My whole web application is developped with urls like
>>
>> http://www.perspectives-musicales.org/en/all-associations
>>
>> for search engine optimizations, where "en" and "all-associations" are
>> not pages or directories, but program arguments (replacing
>> "?lang=en&command=all-associations" which are poor seo)
>
> Right; I built a PHP framework that uses so-called "clean-URLs", and am
> well-versed in the theory behind this approach, as well as its
> execution. The rationale seems sound.
>
>> So, as explained in my first email, all arguments to my application
>> controller are in $_SERVER["PATH_INFO"] (and not
>> $_SERVER["QUERY_STRING"]). And that did work like a charm with
>> mod_php... Changing all my application with data in query_string is not
>> very complicated if I wrote a good program ( :) ) but will need a lot of
>> checks.
>>
>> Actually at the point where I am now, i've already spent some time on it...
>
> My PHP framework functions the same way via mod_php as it does with
> mod_fcgid and mod_fastcgi. I achieved this by using a well-known
> technique to rewrite the URLs (I place these directives into the
> site-root's .htaccess file):
>
> <IfModule mod_rewrite.c>
> RewriteEngine on
> Options All
>
> # Modify the RewriteBase if you are using a subdirectory and the
> # rewrite rules are not working properly:
> # WARNING: Do not include a trailing slash on this directive if you
> # include a path other than /!
> #RewriteBase /
>
> # Rewrite URIs of the form 'index.php?q=x' (except for real
> # files/directories):
> RewriteCond %{REQUEST_FILENAME} !-f
> RewriteCond %{REQUEST_FILENAME} !-d
>
> RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
> </IfModule>
>
> (WordPress, Joomla, and many other frameworks do something similar.)
>
> Then, in PHP, $_GET['q'] will always contain the "clean URL" (unless, of
> course, the 'q' value is overwritten, e.g., the URL contains
> "?q=something-else"). For this reason, you may wish to use something
> other than "q" in the RewriteRule value. You can then parse the
> clean-URL to obtain its "individual segments" and do with them as you
> will. While over simplified, an example is to call explode('/',
> trim($_GET['q'], '/')) in PHP. This will return an array that contains
> the various "path segments". The URL
> http://www.perspectives-musicales.org/en/all-associations would return
>
> array (size=2)
> 0 => string 'en' (length=2)
> 1 => string 'all-associations' (length=16)
>
> Granted, undertaking this approach would mean rewriting certain aspects
> of your application, but chances are that you'll thank yourself later.
> You'll have a much more portable application that is
> scripting-language-agnostic, with respect to URL structure. (Switching
> to another scripting language requires a simple change to your
> RewriteRule only.)
>
>>>
>>> It should be stated that mod_php and mod_fcgid populate these values in
>>> different ways. From what I understand, PATH_INFO is less reliable and
>>> less well-implemented than QUERY_STRING. Fundamentally, this is why you
>>> are observing different behavior/values here after moving from mod_php
>>> to mod_fcgid.
>>
>> I'm not sure that this is a problem with the PATH_INFO variable since
>> the error occurs even before php has any chance to start executing (the
>> test.php is not executed at all in test1)
>
> This may be for the reasons outlined in the article that I cited above.
> If you'd like to post your CGI wrapper script, I'd be happy to take a
> look. Alas, you may lack access to this script, in which case, it's a
> moot point. Although, I must say, it seems unlikely that your host would
> have misconfigured the wrapper script. (Then again, we've all seen worse.)
>
>>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>>> # = parameters are in query_string instead of path_info
>>>
>>> Same as above.
>>>
>>>> RewriteRule ^test4/(.*)
>>>> http://www.perspectives-musicales.org/test.php/$1
>>>> # = redirection 302
>>>
>>> I don't see a 302 response for this one. I see the same 404 and message
>>> as above. Maybe you changed something after sending this message.
>>
>> I use firefox http live header and it shows a status code 302 ("HTTP/1.1
>> 302 Found") then the browser redirect to the page as if it was another
>> website
>
> You're right; I checked this again, and I do see the 302 redirect. I
> think it was a matter of enabling the "Persist" feature in Firebug.
> (Otherwise, the "Net" panel is refreshed after the redirect is sent.)
> Thanks for double-checking your work here!
>
>> I still think that [apache or mod_fcgid] cannot execute test.php in
>> test1 just because it thinks it is a directory and cannot find it.
>
> That may very well be. And the solution I offered above should address
> that shortcoming.
>
> I can't tell you exactly why it doesn't work (only a VPS with shell
> access would make that possible), but I can tell you what *does* work.
>
> I'm happy to answer any questions.
>
> Good luck!
>
> -Ben
>
>>
>>>
>>>> RewriteRule ^test5/(.*) test.php/$1
>>>> # = error 404
>>>>
>>>> RewriteRule ^test6/(.*) /test.php/$1
>>>> # = error 404
>>>
>>> Same as the others with 404 responses.
>>>
>>>>
>>>>
>>>> Thanks for your help.
>>>
>>> You're welcome. I'll wait to hear back before offering additional
>>> information.
>>>
>>> -Ben
>>>
>>>>
>>>>
>>>> On 12/02/13 19:40, Ben Johnson wrote:
>>>>>
>>>>>
>>>>> On 2/12/2013 10:59 AM, Riccardo Cohen wrote:
>>>>>> Thanks Ben, here are the answers :
>>>>>>
>>>>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>>>>
>>>>>> in .htaccess
>>>>>>
>>>>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>>>>
>>>>>> no change with or without
>>>>>>
>>>>>>> 3.) Have you reviewed Apache's access log at all?
>>>>>>
>>>>>> I'll have a look now
>>>>>>
>>>>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly
>>>>>>> what
>>>>>>> the mod_rewrite engine is doing?
>>>>>>
>>>>>> I'll try that. Is it possible to set it in .htacces or must I change
>>>>>> global apache configuration (I only have access to my .htaccess in
>>>>>> this
>>>>>> hosting).
>>>>>
>>>>> Unfortunately, RewriteLogLevel can be set in the "server config" and
>>>>> "virtual host" contexts only. (You can make this type of determination
>>>>> in the future by visiting the manual page and looking for the "context"
>>>>> value:
>>>>> http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewriteloglevel .)
>>>>>
>>>>>
>>>>> This is one of many reasons for which hosting on a VPS over which you
>>>>> have complete control is beneficial.
>>>>>
>>>>> In any case, we'll have to proceed without access to the rewrite log.
>>>>>
>>>>> Is there a specific reason for which you're using "./index.php" in the
>>>>> right-hand side of the rule? I'm referring to the period ("."), in
>>>>> particular. This may well be the source of the problem. It could be
>>>>> that
>>>>> mod_php interprets that relative path (./index.php) "correctly",
>>>>> whereas
>>>>> mod_fcgid does not.
>>>>>
>>>>> Try this:
>>>>>
>>>>> RewriteRule ^en/(.*) index.php/en/$1
>>>>>
>>>>> -Ben
>>>>>
>>>>>
>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> On 12/02/13 14:53, Ben Johnson wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2/12/2013 2:16 AM, Riccardo Cohen wrote:
>>>>>>>> Hello
>>>>>>>> I received some clues from this list members, thanks for that. But
>>>>>>>> unfortunately my problem is not solved.
>>>>>>>>
>>>>>>>> It's not that I want others to focus on me, but I'm quite sure that
>>>>>>>> there is a real problem (if not why would it work perfectly on
>>>>>>>> mod_php
>>>>>>>> ?), I could not find any solution googling about it (even with the
>>>>>>>> help
>>>>>>>> of the host technical team), and I would like a confirmation that 1)
>>>>>>>> it's not an error from my understanding, and 2) there is no
>>>>>>>> workaround
>>>>>>>> for it.
>>>>>>>
>>>>>>> I doubt it is a problem with the software. mod_rewrite has been put
>>>>>>> through the paces over the years and I'd be shocked if a bug were
>>>>>>> uncovered given your rule's relative simplicity.
>>>>>>>
>>>>>>> Before digesting your post in its entirety, I have a couple of
>>>>>>> questions
>>>>>>> first.
>>>>>>>
>>>>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>>>>>
>>>>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>>>>>
>>>>>>> 3.) Have you reviewed Apache's access log at all?
>>>>>>>
>>>>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly
>>>>>>> what
>>>>>>> the mod_rewrite engine is doing?
>>>>>>>
>>>>>>> -Ben
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> So I'll be very pleased to here from some qualified developer
>>>>>>>> before I
>>>>>>>> spend 2 days to modify and retest all my application.
>>>>>>>>
>>>>>>>> Thanks in advance.
>>>>>>>>
>>>>>>>> On 07/02/13 11:17, Riccardo Cohen wrote:
>>>>>>>>> Sorry to insist but I'm really blocked and I really need help.
>>>>>>>>> Here is a small summary for those who don't want to read all :
>>>>>>>>>
>>>>>>>>> I want to make a rewrite from :
>>>>>>>>>
>>>>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>>>>> to
>>>>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>>>>
>>>>>>>>> my rewrite rule is
>>>>>>>>>
>>>>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>>>>
>>>>>>>>> This works when apache is runnnig with mod_php, but not when
>>>>>>>>> running
>>>>>>>>> mod_fcgid (php as cgi). In cgi mode I have a 404 error.
>>>>>>>>>
>>>>>>>>> The Apache version is 2.2.23 and mod_fcgid is version 2.3.7 with
>>>>>>>>> configuration flag cgi.fix_pathinfo=1
>>>>>>>>>
>>>>>>>>> Thanks for your help.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 05/02/13 21:32, Riccardo Cohen wrote:
>>>>>>>>>> Hello
>>>>>>>>>> I'm new to apache mailing list, sorry if I'm not 100% clear, and
>>>>>>>>>> sorry
>>>>>>>>>> for this long description.
>>>>>>>>>>
>>>>>>>>>> I have developped a website with php/mysql :
>>>>>>>>>> http://www.perspectives-musicales.org and placed it on a good
>>>>>>>>>> hosting
>>>>>>>>>> service (web4all.fr).
>>>>>>>>>> To improve search engine rank I decided to set all urls to
>>>>>>>>>> /index.php/... and rewrite them to avoid having index.php in url
>>>>>>>>>> (sort
>>>>>>>>>> of MVC technique combined with SEO...)
>>>>>>>>>>
>>>>>>>>>> Example : the catalog is at url :
>>>>>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>>>>>> This should be transparantly mapped to
>>>>>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>>>>> thanks to
>>>>>>>>>> the rewrite rule :
>>>>>>>>>>
>>>>>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>>>>>
>>>>>>>>>> My application uses then $_SERVER["PATH_INFO"] (and not
>>>>>>>>>> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
>>>>>>>>>> perfectly until last month, because web4all.fr changed the whole
>>>>>>>>>> system
>>>>>>>>>> and separated apache from php, using fast cgi instead of mod_php.
>>>>>>>>>>
>>>>>>>>>> The system is supposed to be more reliable and more efficient like
>>>>>>>>>> this,
>>>>>>>>>> and apparently is. But the rewrite rule does not work anymore.
>>>>>>>>>> So I
>>>>>>>>>> investigated and made some test :
>>>>>>>>>>
>>>>>>>>>> I have a small test.php that displays the path_info and
>>>>>>>>>> query_string.
>>>>>>>>>> You can presently test it here :
>>>>>>>>>>
>>>>>>>>>> http://perspectives-musicales.org/test1/a/b/c
>>>>>>>>>> http://perspectives-musicales.org/test2/a/b/c
>>>>>>>>>> http://perspectives-musicales.org/test3/a/b/c
>>>>>>>>>> http://perspectives-musicales.org/test4/a/b/c
>>>>>>>>>>
>>>>>>>>>> and I set the following rules :
>>>>>>>>>>
>>>>>>>>>> RewriteRule ^test1/(.*) ./test.php/$1
>>>>>>>>>> RewriteRule ^test2/(.*) ./test.php?$1
>>>>>>>>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>>>>>>>>> RewriteRule ^test4/(.*)
>>>>>>>>>> http://www.perspectives-musicales.org/test.php/$1
>>>>>>>>>>
>>>>>>>>>> None of these 4 rewrite rules are convenient. Here is why :
>>>>>>>>>>
>>>>>>>>>> - test1 : the system anwsers 404 "No input file specified". I
>>>>>>>>>> think
>>>>>>>>>> (not
>>>>>>>>>> sure) that Apache beleives that test.php is a folder, and cannot
>>>>>>>>>> find it
>>>>>>>>>> so answers 404
>>>>>>>>>>
>>>>>>>>>> - test2 : the rewrite rule works, but of course the url
>>>>>>>>>> information is
>>>>>>>>>> no more in path_info, it is in query_string as shown in the page
>>>>>>>>>> content
>>>>>>>>>>
>>>>>>>>>> - test3 : same as test2
>>>>>>>>>>
>>>>>>>>>> - test4 : almost good, I can have the url info in path_info, but
>>>>>>>>>> apache
>>>>>>>>>> begins first with a 302 redirection and then changes the url to
>>>>>>>>>> http://www.perspectives-musicales.org/test.php/a/b/c, which
>>>>>>>>>> looses all
>>>>>>>>>> search engine efficiency (and also eventual POST variables if
>>>>>>>>>> any).
>>>>>>>>>>
>>>>>>>>>> My host tried several searches on forums including this one, and
>>>>>>>>>> could
>>>>>>>>>> not find any answer. It seems to be an apache bug, but not sure, I
>>>>>>>>>> have
>>>>>>>>>> no bug number to give anyway. If it is a bug, it is demontrated by
>>>>>>>>>> test1
>>>>>>>>>> I think.
>>>>>>>>>>
>>>>>>>>>> So here is my question : Is there any way to make this rewrite
>>>>>>>>>> rule
>>>>>>>>>> work
>>>>>>>>>> in fastcgi mode, and what is the syntax for it, to keep info in
>>>>>>>>>> path_info without 302 redirection. The Apache version is
>>>>>>>>>> 2.2.23 and
>>>>>>>>>> mod_fcgid is version 2.3.7 with configuration flag
>>>>>>>>>> cgi.fix_pathinfo=1
>>>>>>>>>>
>>>>>>>>>> If there is a way, thanks for your help I'd be glad to test it.
>>>>>>>>>> If no
>>>>>>>>>> could you explain why and how to solve it. As workaround we used
>>>>>>>>>> test4
>>>>>>>>>> syntax in the whole site, to make it work, but it is bad for
>>>>>>>>>> search
>>>>>>>>>> engine, and creates problem in backoffice (because certain
>>>>>>>>>> backoffice
>>>>>>>>>> functions use POST variables)
>>>>>>>>>>
>>>>>>>>>> I know I can change my code to use query_string everywhere
>>>>>>>>>> instead of
>>>>>>>>>> path_info, but if I can avoid changing and testing all my
>>>>>>>>>> websites it
>>>>>>>>>> would be really great
>>>>>>>>>>
>>>>>>>>>> Thanks a lot for your anwser.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite
problem
Posted by "Benoit GEORGELIN (web4all)" <be...@web4all.fr>.
Hi guys,
here is the content of perspectives-musicales.org's wrapper:
#!/bin/sh
# Wrapper PHP w4a
PHPRC="/opt/datas_prod/http1/confs/phpini/perspectives-musicales.org.ini"
PHP_FCGI_MAX_REQUESTS=8000
export PHPRC
export PHP_FCGI_MAX_REQUESTS
exec /opt/w4abin/php/5.2/bin/php-cgi
# Généré par IWAL 20130212-22:02:11
> This may be for the reasons outlined in the article that I cited above.
>i f you'd like to post your CGI wrapper script, I'd be happy to take a
>look. Alas, you may lack access to this script, in which case, it's a
>moot point. Although, I must say, it seems unlikely that your host would
>have misconfigured the wrapper script. (Then again, we've all seen worse.)
If you need more technical information, let me know .
I'll appreciate to solve this issue and understand from where the problem is coming
Regards,
Benoît Georgelin
Web 4 all Hébergeur associatif
----- Mail original -----
De: "Ben Johnson" <be...@indietorrent.org>
À: users@httpd.apache.org
Envoyé: Mercredi 13 Février 2013 22:15:40
Objet: Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
On 2/13/2013 4:14 PM, Riccardo Cohen wrote:
> Hi Ben
>
>>> I tried without the dot : RewriteRule ^en/(.*) index.php/en/$1 but it
>>> gave also an error 404.
>>
>> It would be helpful to know what, exactly, appears in Apache's access
>> log (and/or error log, if you can manage to find that, too) in each of
>> these test cases.
>
> I've asked for the apache error log, and found no error in it.
> Only one which was a request done before adding the new .htaccess, but
> nothing else :
>
> [Tue Feb 12 21:04:17 2013] [error] [client 90.24.101.9] File does not
> exist: /datas/vol1/w4a125552/var/www/perspectives-musicales.org/test6
Very good. No problems there.
>
> The access log show all requests normally with no particular message :
>
> 90.24.101.9 - - [12/Feb/2013:21:04:46 +0100] "GET /test1/a/b/c HTTP/1.1"
> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
> Firefox/18.0" "20130212210446"
>
> 90.24.101.9 - - [12/Feb/2013:21:04:51 +0100] "GET /test2/a/b/c HTTP/1.1"
> 200 52 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
> Firefox/18.0" "20130212210451"
>
> 90.24.101.9 - - [12/Feb/2013:21:04:56 +0100] "GET /test4/a/b/c HTTP/1.1"
> 302 206 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
> Firefox/18.0" "20130212210456"
>
> 90.24.101.9 - - [12/Feb/2013:21:03:28 +0100] "GET /test5/a/b/c HTTP/1.1"
> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
> Firefox/18.0" "20130212210328"
>
> 90.24.101.9 - - [12/Feb/2013:21:04:17 +0100] "GET /test6/a/b/c HTTP/1.1"
> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
> Firefox/18.0" "20130212210417"
This seems to imply that Apache is not generating the 404 errors; if it
were, one would expect access log entries to that effect.
>
>>
>>> These are all my tests : (available at
>>> http://www.perspectives-musicales.org/test1/a/b/c etc.)
>>>
>>> RewriteRule ^test1/(.*) ./test.php/$1
>>> # = error 404
>>
>> I hit this URL and from what I can tell, the 404 response header is
>> coming from PHP, not Apache. The output is "No input file specified."
>> This doesn't look like a "stock" Apache 404 response. Did you build
>> logic into test.php that emits a 404 response header and this message
>> when some parameter is absent from the URL?
>
> test.php is only this :
>
> ok test
> <br>
> <?
> $info=$_SERVER["PATH_INFO"];
> echo "INFO=".$info."<br>";
> $query=$_SERVER["QUERY_STRING"];
> echo "query=".$query."<br>";
> ?>
>
> maybe the error comes from mod_fcgid itself ?
Quite possibly. In fact, a search for "mod_fcgid No input file
specified" yields the following article:
http://isp-control.net/forum/printthread.php?tid=12653
Of particular import is the suggestion, "Okay, this may be caused by
either (1) apache sending an incorrect path to the php file to php5-cgi;
or (2) something (permissions?) that prevents php5-cgi from running the
script."
Do other PHP scripts function as expected when executed via mod_fcgid?
Or do they all return the error string, "No input file specified" and a
404 response?
>>
>>> RewriteRule ^test2/(.*) ./test.php?$1
>>> # = parameters are in query_string instead of path_info
>>
>> Why is this a problem?
>
> My whole web application is developped with urls like
>
> http://www.perspectives-musicales.org/en/all-associations
>
> for search engine optimizations, where "en" and "all-associations" are
> not pages or directories, but program arguments (replacing
> "?lang=en&command=all-associations" which are poor seo)
Right; I built a PHP framework that uses so-called "clean-URLs", and am
well-versed in the theory behind this approach, as well as its
execution. The rationale seems sound.
> So, as explained in my first email, all arguments to my application
> controller are in $_SERVER["PATH_INFO"] (and not
> $_SERVER["QUERY_STRING"]). And that did work like a charm with
> mod_php... Changing all my application with data in query_string is not
> very complicated if I wrote a good program ( :) ) but will need a lot of
> checks.
>
> Actually at the point where I am now, i've already spent some time on it...
My PHP framework functions the same way via mod_php as it does with
mod_fcgid and mod_fastcgi. I achieved this by using a well-known
technique to rewrite the URLs (I place these directives into the
site-root's .htaccess file):
<IfModule mod_rewrite.c>
RewriteEngine on
Options All
# Modify the RewriteBase if you are using a subdirectory and the
# rewrite rules are not working properly:
# WARNING: Do not include a trailing slash on this directive if you
# include a path other than /!
#RewriteBase /
# Rewrite URIs of the form 'index.php?q=x' (except for real
# files/directories):
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>
(WordPress, Joomla, and many other frameworks do something similar.)
Then, in PHP, $_GET['q'] will always contain the "clean URL" (unless, of
course, the 'q' value is overwritten, e.g., the URL contains
"?q=something-else"). For this reason, you may wish to use something
other than "q" in the RewriteRule value. You can then parse the
clean-URL to obtain its "individual segments" and do with them as you
will. While over simplified, an example is to call explode('/',
trim($_GET['q'], '/')) in PHP. This will return an array that contains
the various "path segments". The URL
http://www.perspectives-musicales.org/en/all-associations would return
array (size=2)
0 => string 'en' (length=2)
1 => string 'all-associations' (length=16)
Granted, undertaking this approach would mean rewriting certain aspects
of your application, but chances are that you'll thank yourself later.
You'll have a much more portable application that is
scripting-language-agnostic, with respect to URL structure. (Switching
to another scripting language requires a simple change to your
RewriteRule only.)
>>
>> It should be stated that mod_php and mod_fcgid populate these values in
>> different ways. From what I understand, PATH_INFO is less reliable and
>> less well-implemented than QUERY_STRING. Fundamentally, this is why you
>> are observing different behavior/values here after moving from mod_php
>> to mod_fcgid.
>
> I'm not sure that this is a problem with the PATH_INFO variable since
> the error occurs even before php has any chance to start executing (the
> test.php is not executed at all in test1)
This may be for the reasons outlined in the article that I cited above.
If you'd like to post your CGI wrapper script, I'd be happy to take a
look. Alas, you may lack access to this script, in which case, it's a
moot point. Although, I must say, it seems unlikely that your host would
have misconfigured the wrapper script. (Then again, we've all seen worse.)
>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>> # = parameters are in query_string instead of path_info
>>
>> Same as above.
>>
>>> RewriteRule ^test4/(.*)
>>> http://www.perspectives-musicales.org/test.php/$1
>>> # = redirection 302
>>
>> I don't see a 302 response for this one. I see the same 404 and message
>> as above. Maybe you changed something after sending this message.
>
> I use firefox http live header and it shows a status code 302 ("HTTP/1.1
> 302 Found") then the browser redirect to the page as if it was another
> website
You're right; I checked this again, and I do see the 302 redirect. I
think it was a matter of enabling the "Persist" feature in Firebug.
(Otherwise, the "Net" panel is refreshed after the redirect is sent.)
Thanks for double-checking your work here!
> I still think that [apache or mod_fcgid] cannot execute test.php in
> test1 just because it thinks it is a directory and cannot find it.
That may very well be. And the solution I offered above should address
that shortcoming.
I can't tell you exactly why it doesn't work (only a VPS with shell
access would make that possible), but I can tell you what *does* work.
I'm happy to answer any questions.
Good luck!
-Ben
>
>>
>>> RewriteRule ^test5/(.*) test.php/$1
>>> # = error 404
>>>
>>> RewriteRule ^test6/(.*) /test.php/$1
>>> # = error 404
>>
>> Same as the others with 404 responses.
>>
>>>
>>>
>>> Thanks for your help.
>>
>> You're welcome. I'll wait to hear back before offering additional
>> information.
>>
>> -Ben
>>
>>>
>>>
>>> On 12/02/13 19:40, Ben Johnson wrote:
>>>>
>>>>
>>>> On 2/12/2013 10:59 AM, Riccardo Cohen wrote:
>>>>> Thanks Ben, here are the answers :
>>>>>
>>>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>>>
>>>>> in .htaccess
>>>>>
>>>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>>>
>>>>> no change with or without
>>>>>
>>>>>> 3.) Have you reviewed Apache's access log at all?
>>>>>
>>>>> I'll have a look now
>>>>>
>>>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly
>>>>>> what
>>>>>> the mod_rewrite engine is doing?
>>>>>
>>>>> I'll try that. Is it possible to set it in .htacces or must I change
>>>>> global apache configuration (I only have access to my .htaccess in
>>>>> this
>>>>> hosting).
>>>>
>>>> Unfortunately, RewriteLogLevel can be set in the "server config" and
>>>> "virtual host" contexts only. (You can make this type of determination
>>>> in the future by visiting the manual page and looking for the "context"
>>>> value:
>>>> http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewriteloglevel .)
>>>>
>>>>
>>>> This is one of many reasons for which hosting on a VPS over which you
>>>> have complete control is beneficial.
>>>>
>>>> In any case, we'll have to proceed without access to the rewrite log.
>>>>
>>>> Is there a specific reason for which you're using "./index.php" in the
>>>> right-hand side of the rule? I'm referring to the period ("."), in
>>>> particular. This may well be the source of the problem. It could be
>>>> that
>>>> mod_php interprets that relative path (./index.php) "correctly",
>>>> whereas
>>>> mod_fcgid does not.
>>>>
>>>> Try this:
>>>>
>>>> RewriteRule ^en/(.*) index.php/en/$1
>>>>
>>>> -Ben
>>>>
>>>>
>>>>
>>>>> Thanks
>>>>>
>>>>> On 12/02/13 14:53, Ben Johnson wrote:
>>>>>>
>>>>>>
>>>>>> On 2/12/2013 2:16 AM, Riccardo Cohen wrote:
>>>>>>> Hello
>>>>>>> I received some clues from this list members, thanks for that. But
>>>>>>> unfortunately my problem is not solved.
>>>>>>>
>>>>>>> It's not that I want others to focus on me, but I'm quite sure that
>>>>>>> there is a real problem (if not why would it work perfectly on
>>>>>>> mod_php
>>>>>>> ?), I could not find any solution googling about it (even with the
>>>>>>> help
>>>>>>> of the host technical team), and I would like a confirmation that 1)
>>>>>>> it's not an error from my understanding, and 2) there is no
>>>>>>> workaround
>>>>>>> for it.
>>>>>>
>>>>>> I doubt it is a problem with the software. mod_rewrite has been put
>>>>>> through the paces over the years and I'd be shocked if a bug were
>>>>>> uncovered given your rule's relative simplicity.
>>>>>>
>>>>>> Before digesting your post in its entirety, I have a couple of
>>>>>> questions
>>>>>> first.
>>>>>>
>>>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>>>>
>>>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>>>>
>>>>>> 3.) Have you reviewed Apache's access log at all?
>>>>>>
>>>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly
>>>>>> what
>>>>>> the mod_rewrite engine is doing?
>>>>>>
>>>>>> -Ben
>>>>>>
>>>>>>
>>>>>>
>>>>>>> So I'll be very pleased to here from some qualified developer
>>>>>>> before I
>>>>>>> spend 2 days to modify and retest all my application.
>>>>>>>
>>>>>>> Thanks in advance.
>>>>>>>
>>>>>>> On 07/02/13 11:17, Riccardo Cohen wrote:
>>>>>>>> Sorry to insist but I'm really blocked and I really need help.
>>>>>>>> Here is a small summary for those who don't want to read all :
>>>>>>>>
>>>>>>>> I want to make a rewrite from :
>>>>>>>>
>>>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>>>> to
>>>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>>>
>>>>>>>> my rewrite rule is
>>>>>>>>
>>>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>>>
>>>>>>>> This works when apache is runnnig with mod_php, but not when
>>>>>>>> running
>>>>>>>> mod_fcgid (php as cgi). In cgi mode I have a 404 error.
>>>>>>>>
>>>>>>>> The Apache version is 2.2.23 and mod_fcgid is version 2.3.7 with
>>>>>>>> configuration flag cgi.fix_pathinfo=1
>>>>>>>>
>>>>>>>> Thanks for your help.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/02/13 21:32, Riccardo Cohen wrote:
>>>>>>>>> Hello
>>>>>>>>> I'm new to apache mailing list, sorry if I'm not 100% clear, and
>>>>>>>>> sorry
>>>>>>>>> for this long description.
>>>>>>>>>
>>>>>>>>> I have developped a website with php/mysql :
>>>>>>>>> http://www.perspectives-musicales.org and placed it on a good
>>>>>>>>> hosting
>>>>>>>>> service (web4all.fr).
>>>>>>>>> To improve search engine rank I decided to set all urls to
>>>>>>>>> /index.php/... and rewrite them to avoid having index.php in url
>>>>>>>>> (sort
>>>>>>>>> of MVC technique combined with SEO...)
>>>>>>>>>
>>>>>>>>> Example : the catalog is at url :
>>>>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>>>>> This should be transparantly mapped to
>>>>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>>>> thanks to
>>>>>>>>> the rewrite rule :
>>>>>>>>>
>>>>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>>>>
>>>>>>>>> My application uses then $_SERVER["PATH_INFO"] (and not
>>>>>>>>> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
>>>>>>>>> perfectly until last month, because web4all.fr changed the whole
>>>>>>>>> system
>>>>>>>>> and separated apache from php, using fast cgi instead of mod_php.
>>>>>>>>>
>>>>>>>>> The system is supposed to be more reliable and more efficient like
>>>>>>>>> this,
>>>>>>>>> and apparently is. But the rewrite rule does not work anymore.
>>>>>>>>> So I
>>>>>>>>> investigated and made some test :
>>>>>>>>>
>>>>>>>>> I have a small test.php that displays the path_info and
>>>>>>>>> query_string.
>>>>>>>>> You can presently test it here :
>>>>>>>>>
>>>>>>>>> http://perspectives-musicales.org/test1/a/b/c
>>>>>>>>> http://perspectives-musicales.org/test2/a/b/c
>>>>>>>>> http://perspectives-musicales.org/test3/a/b/c
>>>>>>>>> http://perspectives-musicales.org/test4/a/b/c
>>>>>>>>>
>>>>>>>>> and I set the following rules :
>>>>>>>>>
>>>>>>>>> RewriteRule ^test1/(.*) ./test.php/$1
>>>>>>>>> RewriteRule ^test2/(.*) ./test.php?$1
>>>>>>>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>>>>>>>> RewriteRule ^test4/(.*)
>>>>>>>>> http://www.perspectives-musicales.org/test.php/$1
>>>>>>>>>
>>>>>>>>> None of these 4 rewrite rules are convenient. Here is why :
>>>>>>>>>
>>>>>>>>> - test1 : the system anwsers 404 "No input file specified". I
>>>>>>>>> think
>>>>>>>>> (not
>>>>>>>>> sure) that Apache beleives that test.php is a folder, and cannot
>>>>>>>>> find it
>>>>>>>>> so answers 404
>>>>>>>>>
>>>>>>>>> - test2 : the rewrite rule works, but of course the url
>>>>>>>>> information is
>>>>>>>>> no more in path_info, it is in query_string as shown in the page
>>>>>>>>> content
>>>>>>>>>
>>>>>>>>> - test3 : same as test2
>>>>>>>>>
>>>>>>>>> - test4 : almost good, I can have the url info in path_info, but
>>>>>>>>> apache
>>>>>>>>> begins first with a 302 redirection and then changes the url to
>>>>>>>>> http://www.perspectives-musicales.org/test.php/a/b/c, which
>>>>>>>>> looses all
>>>>>>>>> search engine efficiency (and also eventual POST variables if
>>>>>>>>> any).
>>>>>>>>>
>>>>>>>>> My host tried several searches on forums including this one, and
>>>>>>>>> could
>>>>>>>>> not find any answer. It seems to be an apache bug, but not sure, I
>>>>>>>>> have
>>>>>>>>> no bug number to give anyway. If it is a bug, it is demontrated by
>>>>>>>>> test1
>>>>>>>>> I think.
>>>>>>>>>
>>>>>>>>> So here is my question : Is there any way to make this rewrite
>>>>>>>>> rule
>>>>>>>>> work
>>>>>>>>> in fastcgi mode, and what is the syntax for it, to keep info in
>>>>>>>>> path_info without 302 redirection. The Apache version is
>>>>>>>>> 2.2.23 and
>>>>>>>>> mod_fcgid is version 2.3.7 with configuration flag
>>>>>>>>> cgi.fix_pathinfo=1
>>>>>>>>>
>>>>>>>>> If there is a way, thanks for your help I'd be glad to test it.
>>>>>>>>> If no
>>>>>>>>> could you explain why and how to solve it. As workaround we used
>>>>>>>>> test4
>>>>>>>>> syntax in the whole site, to make it work, but it is bad for
>>>>>>>>> search
>>>>>>>>> engine, and creates problem in backoffice (because certain
>>>>>>>>> backoffice
>>>>>>>>> functions use POST variables)
>>>>>>>>>
>>>>>>>>> I know I can change my code to use query_string everywhere
>>>>>>>>> instead of
>>>>>>>>> path_info, but if I can avoid changing and testing all my
>>>>>>>>> websites it
>>>>>>>>> would be really great
>>>>>>>>>
>>>>>>>>> Thanks a lot for your anwser.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Riccardo Cohen <r....@realty-property.com>.
Hi Ben
I'll follow your advice. I'm really grateful for your help, and wish to
thank you very very much.
Bye
On 14/02/13 17:02, Ben Johnson wrote:
>
>
> On 2/14/2013 4:47 AM, Riccardo Cohen wrote:
>> Hi Ben
>>
>>> Do other PHP scripts function as expected when executed via mod_fcgid?
>>> Or do they all return the error string, "No input file specified" and a
>>> 404 response?
>>
>> Actually my website redirect all urls to /index.php, so there is only
>> one php file (that loads many others). This way I implement a request
>> controller easily.
>
> Okay, so if index.php can be accessed and doesn't return a 404, the
> problem is not with the CGI setup, as a whole.
>
>>> My PHP framework functions the same way via mod_php as it does with
>>> mod_fcgid and mod_fastcgi. I achieved this by using a well-known
>>> technique to rewrite the URLs (I place these directives into the
>>> site-root's .htaccess file):
>>>
>>> <IfModule mod_rewrite.c>
>>> RewriteEngine on
>>> Options All
>>>
>>> # Modify the RewriteBase if you are using a subdirectory and the
>>> # rewrite rules are not working properly:
>>> # WARNING: Do not include a trailing slash on this directive if you
>>> # include a path other than /!
>>> #RewriteBase /
>>>
>>> # Rewrite URIs of the form 'index.php?q=x' (except for real
>>> # files/directories):
>>> RewriteCond %{REQUEST_FILENAME} !-f
>>> RewriteCond %{REQUEST_FILENAME} !-d
>>>
>>> RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
>>> </IfModule>
>>>
>>
>> Yes I understand now that query_string is more portable than path_info.
>> Thanks for the tip.
>
> You're welcome.
>
>>>>
>>>> I'm not sure that this is a problem with the PATH_INFO variable since
>>>> the error occurs even before php has any chance to start executing (the
>>>> test.php is not executed at all in test1)
>>>
>>> This may be for the reasons outlined in the article that I cited above.
>>> If you'd like to post your CGI wrapper script, I'd be happy to take a
>>> look. Alas, you may lack access to this script, in which case, it's a
>>> moot point. Although, I must say, it seems unlikely that your host would
>>> have misconfigured the wrapper script. (Then again, we've all seen
>>> worse.)
>>>
>>
>> See the answer of Benoit Georgelin, he kindly added the script to this
>> thread. Hoping this is the beginning of a solution. I know absolutely
>> nothing about these wrapper scripts.
>>
>
> I have responded to his message.
>
> As I told him, whatever the source of this problem, it seems to be with
> PHP and not Apache.
>
> Here are two PHP bug reports that appear to be relevant, both still open:
>
> Bug #51983 [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1
> https://bugs.php.net/bug.php?id=51983
>
> Bug #55208 setting correct SCRIPT_NAME vs PHP_SELF is impossible in
> certain circumstances
> https://bugs.php.net/bug.php?id=55208
>
> Basically, the consensus is that the cgi.fix_pathinfo directive is a mess.
>
> I wouldn't hold your breath for a resolution. If I were you, I would
> take my good advice, use the Query String Append [QSA] flag, and be done
> with it for good.
>
> In any case, this discussion should probably be moved to a PHP forum or
> mailing list at this point.
>
> Thanks,
>
> -Ben
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
--
Riccardo Cohen
+33 (0)6 09 83 64 49
Société Realty-Property.com
1 rue de la Monnaie
37000 Tours
France
<http://www.appartement-maison.fr>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Ben Johnson <be...@indietorrent.org>.
On 2/14/2013 4:47 AM, Riccardo Cohen wrote:
> Hi Ben
>
>> Do other PHP scripts function as expected when executed via mod_fcgid?
>> Or do they all return the error string, "No input file specified" and a
>> 404 response?
>
> Actually my website redirect all urls to /index.php, so there is only
> one php file (that loads many others). This way I implement a request
> controller easily.
Okay, so if index.php can be accessed and doesn't return a 404, the
problem is not with the CGI setup, as a whole.
>> My PHP framework functions the same way via mod_php as it does with
>> mod_fcgid and mod_fastcgi. I achieved this by using a well-known
>> technique to rewrite the URLs (I place these directives into the
>> site-root's .htaccess file):
>>
>> <IfModule mod_rewrite.c>
>> RewriteEngine on
>> Options All
>>
>> # Modify the RewriteBase if you are using a subdirectory and the
>> # rewrite rules are not working properly:
>> # WARNING: Do not include a trailing slash on this directive if you
>> # include a path other than /!
>> #RewriteBase /
>>
>> # Rewrite URIs of the form 'index.php?q=x' (except for real
>> # files/directories):
>> RewriteCond %{REQUEST_FILENAME} !-f
>> RewriteCond %{REQUEST_FILENAME} !-d
>>
>> RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
>> </IfModule>
>>
>
> Yes I understand now that query_string is more portable than path_info.
> Thanks for the tip.
You're welcome.
>>>
>>> I'm not sure that this is a problem with the PATH_INFO variable since
>>> the error occurs even before php has any chance to start executing (the
>>> test.php is not executed at all in test1)
>>
>> This may be for the reasons outlined in the article that I cited above.
>> If you'd like to post your CGI wrapper script, I'd be happy to take a
>> look. Alas, you may lack access to this script, in which case, it's a
>> moot point. Although, I must say, it seems unlikely that your host would
>> have misconfigured the wrapper script. (Then again, we've all seen
>> worse.)
>>
>
> See the answer of Benoit Georgelin, he kindly added the script to this
> thread. Hoping this is the beginning of a solution. I know absolutely
> nothing about these wrapper scripts.
>
I have responded to his message.
As I told him, whatever the source of this problem, it seems to be with
PHP and not Apache.
Here are two PHP bug reports that appear to be relevant, both still open:
Bug #51983 [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1
https://bugs.php.net/bug.php?id=51983
Bug #55208 setting correct SCRIPT_NAME vs PHP_SELF is impossible in
certain circumstances
https://bugs.php.net/bug.php?id=55208
Basically, the consensus is that the cgi.fix_pathinfo directive is a mess.
I wouldn't hold your breath for a resolution. If I were you, I would
take my good advice, use the Query String Append [QSA] flag, and be done
with it for good.
In any case, this discussion should probably be moved to a PHP forum or
mailing list at this point.
Thanks,
-Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Riccardo Cohen <r....@realty-property.com>.
Hi Ben
> Do other PHP scripts function as expected when executed via mod_fcgid?
> Or do they all return the error string, "No input file specified" and a
> 404 response?
Actually my website redirect all urls to /index.php, so there is only
one php file (that loads many others). This way I implement a request
controller easily.
> My PHP framework functions the same way via mod_php as it does with
> mod_fcgid and mod_fastcgi. I achieved this by using a well-known
> technique to rewrite the URLs (I place these directives into the
> site-root's .htaccess file):
>
> <IfModule mod_rewrite.c>
> RewriteEngine on
> Options All
>
> # Modify the RewriteBase if you are using a subdirectory and the
> # rewrite rules are not working properly:
> # WARNING: Do not include a trailing slash on this directive if you
> # include a path other than /!
> #RewriteBase /
>
> # Rewrite URIs of the form 'index.php?q=x' (except for real
> # files/directories):
> RewriteCond %{REQUEST_FILENAME} !-f
> RewriteCond %{REQUEST_FILENAME} !-d
>
> RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
> </IfModule>
>
Yes I understand now that query_string is more portable than path_info.
Thanks for the tip.
>>
>> I'm not sure that this is a problem with the PATH_INFO variable since
>> the error occurs even before php has any chance to start executing (the
>> test.php is not executed at all in test1)
>
> This may be for the reasons outlined in the article that I cited above.
> If you'd like to post your CGI wrapper script, I'd be happy to take a
> look. Alas, you may lack access to this script, in which case, it's a
> moot point. Although, I must say, it seems unlikely that your host would
> have misconfigured the wrapper script. (Then again, we've all seen worse.)
>
See the answer of Benoit Georgelin, he kindly added the script to this
thread. Hoping this is the beginning of a solution. I know absolutely
nothing about these wrapper scripts.
--
Riccardo Cohen
+33 (0)6 09 83 64 49
Société Realty-Property.com
1 rue de la Monnaie
37000 Tours
France
<http://www.appartement-maison.fr>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Ben Johnson <be...@indietorrent.org>.
On 2/13/2013 4:14 PM, Riccardo Cohen wrote:
> Hi Ben
>
>>> I tried without the dot : RewriteRule ^en/(.*) index.php/en/$1 but it
>>> gave also an error 404.
>>
>> It would be helpful to know what, exactly, appears in Apache's access
>> log (and/or error log, if you can manage to find that, too) in each of
>> these test cases.
>
> I've asked for the apache error log, and found no error in it.
> Only one which was a request done before adding the new .htaccess, but
> nothing else :
>
> [Tue Feb 12 21:04:17 2013] [error] [client 90.24.101.9] File does not
> exist: /datas/vol1/w4a125552/var/www/perspectives-musicales.org/test6
Very good. No problems there.
>
> The access log show all requests normally with no particular message :
>
> 90.24.101.9 - - [12/Feb/2013:21:04:46 +0100] "GET /test1/a/b/c HTTP/1.1"
> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
> Firefox/18.0" "20130212210446"
>
> 90.24.101.9 - - [12/Feb/2013:21:04:51 +0100] "GET /test2/a/b/c HTTP/1.1"
> 200 52 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
> Firefox/18.0" "20130212210451"
>
> 90.24.101.9 - - [12/Feb/2013:21:04:56 +0100] "GET /test4/a/b/c HTTP/1.1"
> 302 206 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
> Firefox/18.0" "20130212210456"
>
> 90.24.101.9 - - [12/Feb/2013:21:03:28 +0100] "GET /test5/a/b/c HTTP/1.1"
> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
> Firefox/18.0" "20130212210328"
>
> 90.24.101.9 - - [12/Feb/2013:21:04:17 +0100] "GET /test6/a/b/c HTTP/1.1"
> 404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
> Firefox/18.0" "20130212210417"
This seems to imply that Apache is not generating the 404 errors; if it
were, one would expect access log entries to that effect.
>
>>
>>> These are all my tests : (available at
>>> http://www.perspectives-musicales.org/test1/a/b/c etc.)
>>>
>>> RewriteRule ^test1/(.*) ./test.php/$1
>>> # = error 404
>>
>> I hit this URL and from what I can tell, the 404 response header is
>> coming from PHP, not Apache. The output is "No input file specified."
>> This doesn't look like a "stock" Apache 404 response. Did you build
>> logic into test.php that emits a 404 response header and this message
>> when some parameter is absent from the URL?
>
> test.php is only this :
>
> ok test
> <br>
> <?
> $info=$_SERVER["PATH_INFO"];
> echo "INFO=".$info."<br>";
> $query=$_SERVER["QUERY_STRING"];
> echo "query=".$query."<br>";
> ?>
>
> maybe the error comes from mod_fcgid itself ?
Quite possibly. In fact, a search for "mod_fcgid No input file
specified" yields the following article:
http://isp-control.net/forum/printthread.php?tid=12653
Of particular import is the suggestion, "Okay, this may be caused by
either (1) apache sending an incorrect path to the php file to php5-cgi;
or (2) something (permissions?) that prevents php5-cgi from running the
script."
Do other PHP scripts function as expected when executed via mod_fcgid?
Or do they all return the error string, "No input file specified" and a
404 response?
>>
>>> RewriteRule ^test2/(.*) ./test.php?$1
>>> # = parameters are in query_string instead of path_info
>>
>> Why is this a problem?
>
> My whole web application is developped with urls like
>
> http://www.perspectives-musicales.org/en/all-associations
>
> for search engine optimizations, where "en" and "all-associations" are
> not pages or directories, but program arguments (replacing
> "?lang=en&command=all-associations" which are poor seo)
Right; I built a PHP framework that uses so-called "clean-URLs", and am
well-versed in the theory behind this approach, as well as its
execution. The rationale seems sound.
> So, as explained in my first email, all arguments to my application
> controller are in $_SERVER["PATH_INFO"] (and not
> $_SERVER["QUERY_STRING"]). And that did work like a charm with
> mod_php... Changing all my application with data in query_string is not
> very complicated if I wrote a good program ( :) ) but will need a lot of
> checks.
>
> Actually at the point where I am now, i've already spent some time on it...
My PHP framework functions the same way via mod_php as it does with
mod_fcgid and mod_fastcgi. I achieved this by using a well-known
technique to rewrite the URLs (I place these directives into the
site-root's .htaccess file):
<IfModule mod_rewrite.c>
RewriteEngine on
Options All
# Modify the RewriteBase if you are using a subdirectory and the
# rewrite rules are not working properly:
# WARNING: Do not include a trailing slash on this directive if you
# include a path other than /!
#RewriteBase /
# Rewrite URIs of the form 'index.php?q=x' (except for real
# files/directories):
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>
(WordPress, Joomla, and many other frameworks do something similar.)
Then, in PHP, $_GET['q'] will always contain the "clean URL" (unless, of
course, the 'q' value is overwritten, e.g., the URL contains
"?q=something-else"). For this reason, you may wish to use something
other than "q" in the RewriteRule value. You can then parse the
clean-URL to obtain its "individual segments" and do with them as you
will. While over simplified, an example is to call explode('/',
trim($_GET['q'], '/')) in PHP. This will return an array that contains
the various "path segments". The URL
http://www.perspectives-musicales.org/en/all-associations would return
array (size=2)
0 => string 'en' (length=2)
1 => string 'all-associations' (length=16)
Granted, undertaking this approach would mean rewriting certain aspects
of your application, but chances are that you'll thank yourself later.
You'll have a much more portable application that is
scripting-language-agnostic, with respect to URL structure. (Switching
to another scripting language requires a simple change to your
RewriteRule only.)
>>
>> It should be stated that mod_php and mod_fcgid populate these values in
>> different ways. From what I understand, PATH_INFO is less reliable and
>> less well-implemented than QUERY_STRING. Fundamentally, this is why you
>> are observing different behavior/values here after moving from mod_php
>> to mod_fcgid.
>
> I'm not sure that this is a problem with the PATH_INFO variable since
> the error occurs even before php has any chance to start executing (the
> test.php is not executed at all in test1)
This may be for the reasons outlined in the article that I cited above.
If you'd like to post your CGI wrapper script, I'd be happy to take a
look. Alas, you may lack access to this script, in which case, it's a
moot point. Although, I must say, it seems unlikely that your host would
have misconfigured the wrapper script. (Then again, we've all seen worse.)
>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>> # = parameters are in query_string instead of path_info
>>
>> Same as above.
>>
>>> RewriteRule ^test4/(.*)
>>> http://www.perspectives-musicales.org/test.php/$1
>>> # = redirection 302
>>
>> I don't see a 302 response for this one. I see the same 404 and message
>> as above. Maybe you changed something after sending this message.
>
> I use firefox http live header and it shows a status code 302 ("HTTP/1.1
> 302 Found") then the browser redirect to the page as if it was another
> website
You're right; I checked this again, and I do see the 302 redirect. I
think it was a matter of enabling the "Persist" feature in Firebug.
(Otherwise, the "Net" panel is refreshed after the redirect is sent.)
Thanks for double-checking your work here!
> I still think that [apache or mod_fcgid] cannot execute test.php in
> test1 just because it thinks it is a directory and cannot find it.
That may very well be. And the solution I offered above should address
that shortcoming.
I can't tell you exactly why it doesn't work (only a VPS with shell
access would make that possible), but I can tell you what *does* work.
I'm happy to answer any questions.
Good luck!
-Ben
>
>>
>>> RewriteRule ^test5/(.*) test.php/$1
>>> # = error 404
>>>
>>> RewriteRule ^test6/(.*) /test.php/$1
>>> # = error 404
>>
>> Same as the others with 404 responses.
>>
>>>
>>>
>>> Thanks for your help.
>>
>> You're welcome. I'll wait to hear back before offering additional
>> information.
>>
>> -Ben
>>
>>>
>>>
>>> On 12/02/13 19:40, Ben Johnson wrote:
>>>>
>>>>
>>>> On 2/12/2013 10:59 AM, Riccardo Cohen wrote:
>>>>> Thanks Ben, here are the answers :
>>>>>
>>>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>>>
>>>>> in .htaccess
>>>>>
>>>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>>>
>>>>> no change with or without
>>>>>
>>>>>> 3.) Have you reviewed Apache's access log at all?
>>>>>
>>>>> I'll have a look now
>>>>>
>>>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly
>>>>>> what
>>>>>> the mod_rewrite engine is doing?
>>>>>
>>>>> I'll try that. Is it possible to set it in .htacces or must I change
>>>>> global apache configuration (I only have access to my .htaccess in
>>>>> this
>>>>> hosting).
>>>>
>>>> Unfortunately, RewriteLogLevel can be set in the "server config" and
>>>> "virtual host" contexts only. (You can make this type of determination
>>>> in the future by visiting the manual page and looking for the "context"
>>>> value:
>>>> http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewriteloglevel .)
>>>>
>>>>
>>>> This is one of many reasons for which hosting on a VPS over which you
>>>> have complete control is beneficial.
>>>>
>>>> In any case, we'll have to proceed without access to the rewrite log.
>>>>
>>>> Is there a specific reason for which you're using "./index.php" in the
>>>> right-hand side of the rule? I'm referring to the period ("."), in
>>>> particular. This may well be the source of the problem. It could be
>>>> that
>>>> mod_php interprets that relative path (./index.php) "correctly",
>>>> whereas
>>>> mod_fcgid does not.
>>>>
>>>> Try this:
>>>>
>>>> RewriteRule ^en/(.*) index.php/en/$1
>>>>
>>>> -Ben
>>>>
>>>>
>>>>
>>>>> Thanks
>>>>>
>>>>> On 12/02/13 14:53, Ben Johnson wrote:
>>>>>>
>>>>>>
>>>>>> On 2/12/2013 2:16 AM, Riccardo Cohen wrote:
>>>>>>> Hello
>>>>>>> I received some clues from this list members, thanks for that. But
>>>>>>> unfortunately my problem is not solved.
>>>>>>>
>>>>>>> It's not that I want others to focus on me, but I'm quite sure that
>>>>>>> there is a real problem (if not why would it work perfectly on
>>>>>>> mod_php
>>>>>>> ?), I could not find any solution googling about it (even with the
>>>>>>> help
>>>>>>> of the host technical team), and I would like a confirmation that 1)
>>>>>>> it's not an error from my understanding, and 2) there is no
>>>>>>> workaround
>>>>>>> for it.
>>>>>>
>>>>>> I doubt it is a problem with the software. mod_rewrite has been put
>>>>>> through the paces over the years and I'd be shocked if a bug were
>>>>>> uncovered given your rule's relative simplicity.
>>>>>>
>>>>>> Before digesting your post in its entirety, I have a couple of
>>>>>> questions
>>>>>> first.
>>>>>>
>>>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>>>>
>>>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>>>>
>>>>>> 3.) Have you reviewed Apache's access log at all?
>>>>>>
>>>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly
>>>>>> what
>>>>>> the mod_rewrite engine is doing?
>>>>>>
>>>>>> -Ben
>>>>>>
>>>>>>
>>>>>>
>>>>>>> So I'll be very pleased to here from some qualified developer
>>>>>>> before I
>>>>>>> spend 2 days to modify and retest all my application.
>>>>>>>
>>>>>>> Thanks in advance.
>>>>>>>
>>>>>>> On 07/02/13 11:17, Riccardo Cohen wrote:
>>>>>>>> Sorry to insist but I'm really blocked and I really need help.
>>>>>>>> Here is a small summary for those who don't want to read all :
>>>>>>>>
>>>>>>>> I want to make a rewrite from :
>>>>>>>>
>>>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>>>> to
>>>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>>>
>>>>>>>> my rewrite rule is
>>>>>>>>
>>>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>>>
>>>>>>>> This works when apache is runnnig with mod_php, but not when
>>>>>>>> running
>>>>>>>> mod_fcgid (php as cgi). In cgi mode I have a 404 error.
>>>>>>>>
>>>>>>>> The Apache version is 2.2.23 and mod_fcgid is version 2.3.7 with
>>>>>>>> configuration flag cgi.fix_pathinfo=1
>>>>>>>>
>>>>>>>> Thanks for your help.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/02/13 21:32, Riccardo Cohen wrote:
>>>>>>>>> Hello
>>>>>>>>> I'm new to apache mailing list, sorry if I'm not 100% clear, and
>>>>>>>>> sorry
>>>>>>>>> for this long description.
>>>>>>>>>
>>>>>>>>> I have developped a website with php/mysql :
>>>>>>>>> http://www.perspectives-musicales.org and placed it on a good
>>>>>>>>> hosting
>>>>>>>>> service (web4all.fr).
>>>>>>>>> To improve search engine rank I decided to set all urls to
>>>>>>>>> /index.php/... and rewrite them to avoid having index.php in url
>>>>>>>>> (sort
>>>>>>>>> of MVC technique combined with SEO...)
>>>>>>>>>
>>>>>>>>> Example : the catalog is at url :
>>>>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>>>>> This should be transparantly mapped to
>>>>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>>>> thanks to
>>>>>>>>> the rewrite rule :
>>>>>>>>>
>>>>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>>>>
>>>>>>>>> My application uses then $_SERVER["PATH_INFO"] (and not
>>>>>>>>> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
>>>>>>>>> perfectly until last month, because web4all.fr changed the whole
>>>>>>>>> system
>>>>>>>>> and separated apache from php, using fast cgi instead of mod_php.
>>>>>>>>>
>>>>>>>>> The system is supposed to be more reliable and more efficient like
>>>>>>>>> this,
>>>>>>>>> and apparently is. But the rewrite rule does not work anymore.
>>>>>>>>> So I
>>>>>>>>> investigated and made some test :
>>>>>>>>>
>>>>>>>>> I have a small test.php that displays the path_info and
>>>>>>>>> query_string.
>>>>>>>>> You can presently test it here :
>>>>>>>>>
>>>>>>>>> http://perspectives-musicales.org/test1/a/b/c
>>>>>>>>> http://perspectives-musicales.org/test2/a/b/c
>>>>>>>>> http://perspectives-musicales.org/test3/a/b/c
>>>>>>>>> http://perspectives-musicales.org/test4/a/b/c
>>>>>>>>>
>>>>>>>>> and I set the following rules :
>>>>>>>>>
>>>>>>>>> RewriteRule ^test1/(.*) ./test.php/$1
>>>>>>>>> RewriteRule ^test2/(.*) ./test.php?$1
>>>>>>>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>>>>>>>> RewriteRule ^test4/(.*)
>>>>>>>>> http://www.perspectives-musicales.org/test.php/$1
>>>>>>>>>
>>>>>>>>> None of these 4 rewrite rules are convenient. Here is why :
>>>>>>>>>
>>>>>>>>> - test1 : the system anwsers 404 "No input file specified". I
>>>>>>>>> think
>>>>>>>>> (not
>>>>>>>>> sure) that Apache beleives that test.php is a folder, and cannot
>>>>>>>>> find it
>>>>>>>>> so answers 404
>>>>>>>>>
>>>>>>>>> - test2 : the rewrite rule works, but of course the url
>>>>>>>>> information is
>>>>>>>>> no more in path_info, it is in query_string as shown in the page
>>>>>>>>> content
>>>>>>>>>
>>>>>>>>> - test3 : same as test2
>>>>>>>>>
>>>>>>>>> - test4 : almost good, I can have the url info in path_info, but
>>>>>>>>> apache
>>>>>>>>> begins first with a 302 redirection and then changes the url to
>>>>>>>>> http://www.perspectives-musicales.org/test.php/a/b/c, which
>>>>>>>>> looses all
>>>>>>>>> search engine efficiency (and also eventual POST variables if
>>>>>>>>> any).
>>>>>>>>>
>>>>>>>>> My host tried several searches on forums including this one, and
>>>>>>>>> could
>>>>>>>>> not find any answer. It seems to be an apache bug, but not sure, I
>>>>>>>>> have
>>>>>>>>> no bug number to give anyway. If it is a bug, it is demontrated by
>>>>>>>>> test1
>>>>>>>>> I think.
>>>>>>>>>
>>>>>>>>> So here is my question : Is there any way to make this rewrite
>>>>>>>>> rule
>>>>>>>>> work
>>>>>>>>> in fastcgi mode, and what is the syntax for it, to keep info in
>>>>>>>>> path_info without 302 redirection. The Apache version is
>>>>>>>>> 2.2.23 and
>>>>>>>>> mod_fcgid is version 2.3.7 with configuration flag
>>>>>>>>> cgi.fix_pathinfo=1
>>>>>>>>>
>>>>>>>>> If there is a way, thanks for your help I'd be glad to test it.
>>>>>>>>> If no
>>>>>>>>> could you explain why and how to solve it. As workaround we used
>>>>>>>>> test4
>>>>>>>>> syntax in the whole site, to make it work, but it is bad for
>>>>>>>>> search
>>>>>>>>> engine, and creates problem in backoffice (because certain
>>>>>>>>> backoffice
>>>>>>>>> functions use POST variables)
>>>>>>>>>
>>>>>>>>> I know I can change my code to use query_string everywhere
>>>>>>>>> instead of
>>>>>>>>> path_info, but if I can avoid changing and testing all my
>>>>>>>>> websites it
>>>>>>>>> would be really great
>>>>>>>>>
>>>>>>>>> Thanks a lot for your anwser.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Riccardo Cohen <r....@realty-property.com>.
Hi Ben
>> I tried without the dot : RewriteRule ^en/(.*) index.php/en/$1 but it
>> gave also an error 404.
>
> It would be helpful to know what, exactly, appears in Apache's access
> log (and/or error log, if you can manage to find that, too) in each of
> these test cases.
I've asked for the apache error log, and found no error in it.
Only one which was a request done before adding the new .htaccess, but
nothing else :
[Tue Feb 12 21:04:17 2013] [error] [client 90.24.101.9] File does not
exist: /datas/vol1/w4a125552/var/www/perspectives-musicales.org/test6
The access log show all requests normally with no particular message :
90.24.101.9 - - [12/Feb/2013:21:04:46 +0100] "GET /test1/a/b/c HTTP/1.1"
404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
Firefox/18.0" "20130212210446"
90.24.101.9 - - [12/Feb/2013:21:04:51 +0100] "GET /test2/a/b/c HTTP/1.1"
200 52 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
Firefox/18.0" "20130212210451"
90.24.101.9 - - [12/Feb/2013:21:04:56 +0100] "GET /test4/a/b/c HTTP/1.1"
302 206 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
Firefox/18.0" "20130212210456"
90.24.101.9 - - [12/Feb/2013:21:03:28 +0100] "GET /test5/a/b/c HTTP/1.1"
404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
Firefox/18.0" "20130212210328"
90.24.101.9 - - [12/Feb/2013:21:04:17 +0100] "GET /test6/a/b/c HTTP/1.1"
404 45 "-" "Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101
Firefox/18.0" "20130212210417"
>
>> These are all my tests : (available at
>> http://www.perspectives-musicales.org/test1/a/b/c etc.)
>>
>> RewriteRule ^test1/(.*) ./test.php/$1
>> # = error 404
>
> I hit this URL and from what I can tell, the 404 response header is
> coming from PHP, not Apache. The output is "No input file specified."
> This doesn't look like a "stock" Apache 404 response. Did you build
> logic into test.php that emits a 404 response header and this message
> when some parameter is absent from the URL?
test.php is only this :
ok test
<br>
<?
$info=$_SERVER["PATH_INFO"];
echo "INFO=".$info."<br>";
$query=$_SERVER["QUERY_STRING"];
echo "query=".$query."<br>";
?>
maybe the error comes from mod_fcgid itself ?
>
>> RewriteRule ^test2/(.*) ./test.php?$1
>> # = parameters are in query_string instead of path_info
>
> Why is this a problem?
My whole web application is developped with urls like
http://www.perspectives-musicales.org/en/all-associations
for search engine optimizations, where "en" and "all-associations" are
not pages or directories, but program arguments (replacing
"?lang=en&command=all-associations" which are poor seo)
So, as explained in my first email, all arguments to my application
controller are in $_SERVER["PATH_INFO"] (and not
$_SERVER["QUERY_STRING"]). And that did work like a charm with
mod_php... Changing all my application with data in query_string is not
very complicated if I wrote a good program ( :) ) but will need a lot of
checks.
Actually at the point where I am now, i've already spent some time on it...
>
> It should be stated that mod_php and mod_fcgid populate these values in
> different ways. From what I understand, PATH_INFO is less reliable and
> less well-implemented than QUERY_STRING. Fundamentally, this is why you
> are observing different behavior/values here after moving from mod_php
> to mod_fcgid.
I'm not sure that this is a problem with the PATH_INFO variable since
the error occurs even before php has any chance to start executing (the
test.php is not executed at all in test1)
>> RewriteRule ^test3/(.*) ./test.php?/$1
>> # = parameters are in query_string instead of path_info
>
> Same as above.
>
>> RewriteRule ^test4/(.*) http://www.perspectives-musicales.org/test.php/$1
>> # = redirection 302
>
> I don't see a 302 response for this one. I see the same 404 and message
> as above. Maybe you changed something after sending this message.
I use firefox http live header and it shows a status code 302 ("HTTP/1.1
302 Found") then the browser redirect to the page as if it was another
website
I still think that [apache or mod_fcgid] cannot execute test.php in
test1 just because it thinks it is a directory and cannot find it.
>
>> RewriteRule ^test5/(.*) test.php/$1
>> # = error 404
>>
>> RewriteRule ^test6/(.*) /test.php/$1
>> # = error 404
>
> Same as the others with 404 responses.
>
>>
>>
>> Thanks for your help.
>
> You're welcome. I'll wait to hear back before offering additional
> information.
>
> -Ben
>
>>
>>
>> On 12/02/13 19:40, Ben Johnson wrote:
>>>
>>>
>>> On 2/12/2013 10:59 AM, Riccardo Cohen wrote:
>>>> Thanks Ben, here are the answers :
>>>>
>>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>>
>>>> in .htaccess
>>>>
>>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>>
>>>> no change with or without
>>>>
>>>>> 3.) Have you reviewed Apache's access log at all?
>>>>
>>>> I'll have a look now
>>>>
>>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly what
>>>>> the mod_rewrite engine is doing?
>>>>
>>>> I'll try that. Is it possible to set it in .htacces or must I change
>>>> global apache configuration (I only have access to my .htaccess in this
>>>> hosting).
>>>
>>> Unfortunately, RewriteLogLevel can be set in the "server config" and
>>> "virtual host" contexts only. (You can make this type of determination
>>> in the future by visiting the manual page and looking for the "context"
>>> value:
>>> http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewriteloglevel .)
>>>
>>> This is one of many reasons for which hosting on a VPS over which you
>>> have complete control is beneficial.
>>>
>>> In any case, we'll have to proceed without access to the rewrite log.
>>>
>>> Is there a specific reason for which you're using "./index.php" in the
>>> right-hand side of the rule? I'm referring to the period ("."), in
>>> particular. This may well be the source of the problem. It could be that
>>> mod_php interprets that relative path (./index.php) "correctly", whereas
>>> mod_fcgid does not.
>>>
>>> Try this:
>>>
>>> RewriteRule ^en/(.*) index.php/en/$1
>>>
>>> -Ben
>>>
>>>
>>>
>>>> Thanks
>>>>
>>>> On 12/02/13 14:53, Ben Johnson wrote:
>>>>>
>>>>>
>>>>> On 2/12/2013 2:16 AM, Riccardo Cohen wrote:
>>>>>> Hello
>>>>>> I received some clues from this list members, thanks for that. But
>>>>>> unfortunately my problem is not solved.
>>>>>>
>>>>>> It's not that I want others to focus on me, but I'm quite sure that
>>>>>> there is a real problem (if not why would it work perfectly on mod_php
>>>>>> ?), I could not find any solution googling about it (even with the
>>>>>> help
>>>>>> of the host technical team), and I would like a confirmation that 1)
>>>>>> it's not an error from my understanding, and 2) there is no workaround
>>>>>> for it.
>>>>>
>>>>> I doubt it is a problem with the software. mod_rewrite has been put
>>>>> through the paces over the years and I'd be shocked if a bug were
>>>>> uncovered given your rule's relative simplicity.
>>>>>
>>>>> Before digesting your post in its entirety, I have a couple of
>>>>> questions
>>>>> first.
>>>>>
>>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>>>
>>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>>>
>>>>> 3.) Have you reviewed Apache's access log at all?
>>>>>
>>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly what
>>>>> the mod_rewrite engine is doing?
>>>>>
>>>>> -Ben
>>>>>
>>>>>
>>>>>
>>>>>> So I'll be very pleased to here from some qualified developer before I
>>>>>> spend 2 days to modify and retest all my application.
>>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>> On 07/02/13 11:17, Riccardo Cohen wrote:
>>>>>>> Sorry to insist but I'm really blocked and I really need help.
>>>>>>> Here is a small summary for those who don't want to read all :
>>>>>>>
>>>>>>> I want to make a rewrite from :
>>>>>>>
>>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>>> to
>>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>>
>>>>>>> my rewrite rule is
>>>>>>>
>>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>>
>>>>>>> This works when apache is runnnig with mod_php, but not when running
>>>>>>> mod_fcgid (php as cgi). In cgi mode I have a 404 error.
>>>>>>>
>>>>>>> The Apache version is 2.2.23 and mod_fcgid is version 2.3.7 with
>>>>>>> configuration flag cgi.fix_pathinfo=1
>>>>>>>
>>>>>>> Thanks for your help.
>>>>>>>
>>>>>>>
>>>>>>> On 05/02/13 21:32, Riccardo Cohen wrote:
>>>>>>>> Hello
>>>>>>>> I'm new to apache mailing list, sorry if I'm not 100% clear, and
>>>>>>>> sorry
>>>>>>>> for this long description.
>>>>>>>>
>>>>>>>> I have developped a website with php/mysql :
>>>>>>>> http://www.perspectives-musicales.org and placed it on a good
>>>>>>>> hosting
>>>>>>>> service (web4all.fr).
>>>>>>>> To improve search engine rank I decided to set all urls to
>>>>>>>> /index.php/... and rewrite them to avoid having index.php in url
>>>>>>>> (sort
>>>>>>>> of MVC technique combined with SEO...)
>>>>>>>>
>>>>>>>> Example : the catalog is at url :
>>>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>>>> This should be transparantly mapped to
>>>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>>> thanks to
>>>>>>>> the rewrite rule :
>>>>>>>>
>>>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>>>
>>>>>>>> My application uses then $_SERVER["PATH_INFO"] (and not
>>>>>>>> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
>>>>>>>> perfectly until last month, because web4all.fr changed the whole
>>>>>>>> system
>>>>>>>> and separated apache from php, using fast cgi instead of mod_php.
>>>>>>>>
>>>>>>>> The system is supposed to be more reliable and more efficient like
>>>>>>>> this,
>>>>>>>> and apparently is. But the rewrite rule does not work anymore. So I
>>>>>>>> investigated and made some test :
>>>>>>>>
>>>>>>>> I have a small test.php that displays the path_info and
>>>>>>>> query_string.
>>>>>>>> You can presently test it here :
>>>>>>>>
>>>>>>>> http://perspectives-musicales.org/test1/a/b/c
>>>>>>>> http://perspectives-musicales.org/test2/a/b/c
>>>>>>>> http://perspectives-musicales.org/test3/a/b/c
>>>>>>>> http://perspectives-musicales.org/test4/a/b/c
>>>>>>>>
>>>>>>>> and I set the following rules :
>>>>>>>>
>>>>>>>> RewriteRule ^test1/(.*) ./test.php/$1
>>>>>>>> RewriteRule ^test2/(.*) ./test.php?$1
>>>>>>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>>>>>>> RewriteRule ^test4/(.*)
>>>>>>>> http://www.perspectives-musicales.org/test.php/$1
>>>>>>>>
>>>>>>>> None of these 4 rewrite rules are convenient. Here is why :
>>>>>>>>
>>>>>>>> - test1 : the system anwsers 404 "No input file specified". I think
>>>>>>>> (not
>>>>>>>> sure) that Apache beleives that test.php is a folder, and cannot
>>>>>>>> find it
>>>>>>>> so answers 404
>>>>>>>>
>>>>>>>> - test2 : the rewrite rule works, but of course the url
>>>>>>>> information is
>>>>>>>> no more in path_info, it is in query_string as shown in the page
>>>>>>>> content
>>>>>>>>
>>>>>>>> - test3 : same as test2
>>>>>>>>
>>>>>>>> - test4 : almost good, I can have the url info in path_info, but
>>>>>>>> apache
>>>>>>>> begins first with a 302 redirection and then changes the url to
>>>>>>>> http://www.perspectives-musicales.org/test.php/a/b/c, which
>>>>>>>> looses all
>>>>>>>> search engine efficiency (and also eventual POST variables if any).
>>>>>>>>
>>>>>>>> My host tried several searches on forums including this one, and
>>>>>>>> could
>>>>>>>> not find any answer. It seems to be an apache bug, but not sure, I
>>>>>>>> have
>>>>>>>> no bug number to give anyway. If it is a bug, it is demontrated by
>>>>>>>> test1
>>>>>>>> I think.
>>>>>>>>
>>>>>>>> So here is my question : Is there any way to make this rewrite rule
>>>>>>>> work
>>>>>>>> in fastcgi mode, and what is the syntax for it, to keep info in
>>>>>>>> path_info without 302 redirection. The Apache version is 2.2.23 and
>>>>>>>> mod_fcgid is version 2.3.7 with configuration flag
>>>>>>>> cgi.fix_pathinfo=1
>>>>>>>>
>>>>>>>> If there is a way, thanks for your help I'd be glad to test it.
>>>>>>>> If no
>>>>>>>> could you explain why and how to solve it. As workaround we used
>>>>>>>> test4
>>>>>>>> syntax in the whole site, to make it work, but it is bad for search
>>>>>>>> engine, and creates problem in backoffice (because certain
>>>>>>>> backoffice
>>>>>>>> functions use POST variables)
>>>>>>>>
>>>>>>>> I know I can change my code to use query_string everywhere
>>>>>>>> instead of
>>>>>>>> path_info, but if I can avoid changing and testing all my
>>>>>>>> websites it
>>>>>>>> would be really great
>>>>>>>>
>>>>>>>> Thanks a lot for your anwser.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
--
Riccardo Cohen
+33 (0)6 09 83 64 49
Société Realty-Property.com
1 rue de la Monnaie
37000 Tours
France
<http://www.appartement-maison.fr>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Ben Johnson <be...@indietorrent.org>.
On 2/12/2013 3:19 PM, Riccardo Cohen wrote:
> Hi Ben
> I tried without the dot : RewriteRule ^en/(.*) index.php/en/$1 but it
> gave also an error 404.
It would be helpful to know what, exactly, appears in Apache's access
log (and/or error log, if you can manage to find that, too) in each of
these test cases.
> These are all my tests : (available at
> http://www.perspectives-musicales.org/test1/a/b/c etc.)
>
> RewriteRule ^test1/(.*) ./test.php/$1
> # = error 404
I hit this URL and from what I can tell, the 404 response header is
coming from PHP, not Apache. The output is "No input file specified."
This doesn't look like a "stock" Apache 404 response. Did you build
logic into test.php that emits a 404 response header and this message
when some parameter is absent from the URL?
> RewriteRule ^test2/(.*) ./test.php?$1
> # = parameters are in query_string instead of path_info
Why is this a problem?
It should be stated that mod_php and mod_fcgid populate these values in
different ways. From what I understand, PATH_INFO is less reliable and
less well-implemented than QUERY_STRING. Fundamentally, this is why you
are observing different behavior/values here after moving from mod_php
to mod_fcgid.
> RewriteRule ^test3/(.*) ./test.php?/$1
> # = parameters are in query_string instead of path_info
Same as above.
> RewriteRule ^test4/(.*) http://www.perspectives-musicales.org/test.php/$1
> # = redirection 302
I don't see a 302 response for this one. I see the same 404 and message
as above. Maybe you changed something after sending this message.
> RewriteRule ^test5/(.*) test.php/$1
> # = error 404
>
> RewriteRule ^test6/(.*) /test.php/$1
> # = error 404
Same as the others with 404 responses.
>
> I could not find the apache error log, so I'll ask my hosting support
> team and get back to you
>
> Thanks for your help.
You're welcome. I'll wait to hear back before offering additional
information.
-Ben
>
>
> On 12/02/13 19:40, Ben Johnson wrote:
>>
>>
>> On 2/12/2013 10:59 AM, Riccardo Cohen wrote:
>>> Thanks Ben, here are the answers :
>>>
>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>
>>> in .htaccess
>>>
>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>
>>> no change with or without
>>>
>>>> 3.) Have you reviewed Apache's access log at all?
>>>
>>> I'll have a look now
>>>
>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly what
>>>> the mod_rewrite engine is doing?
>>>
>>> I'll try that. Is it possible to set it in .htacces or must I change
>>> global apache configuration (I only have access to my .htaccess in this
>>> hosting).
>>
>> Unfortunately, RewriteLogLevel can be set in the "server config" and
>> "virtual host" contexts only. (You can make this type of determination
>> in the future by visiting the manual page and looking for the "context"
>> value:
>> http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewriteloglevel .)
>>
>> This is one of many reasons for which hosting on a VPS over which you
>> have complete control is beneficial.
>>
>> In any case, we'll have to proceed without access to the rewrite log.
>>
>> Is there a specific reason for which you're using "./index.php" in the
>> right-hand side of the rule? I'm referring to the period ("."), in
>> particular. This may well be the source of the problem. It could be that
>> mod_php interprets that relative path (./index.php) "correctly", whereas
>> mod_fcgid does not.
>>
>> Try this:
>>
>> RewriteRule ^en/(.*) index.php/en/$1
>>
>> -Ben
>>
>>
>>
>>> Thanks
>>>
>>> On 12/02/13 14:53, Ben Johnson wrote:
>>>>
>>>>
>>>> On 2/12/2013 2:16 AM, Riccardo Cohen wrote:
>>>>> Hello
>>>>> I received some clues from this list members, thanks for that. But
>>>>> unfortunately my problem is not solved.
>>>>>
>>>>> It's not that I want others to focus on me, but I'm quite sure that
>>>>> there is a real problem (if not why would it work perfectly on mod_php
>>>>> ?), I could not find any solution googling about it (even with the
>>>>> help
>>>>> of the host technical team), and I would like a confirmation that 1)
>>>>> it's not an error from my understanding, and 2) there is no workaround
>>>>> for it.
>>>>
>>>> I doubt it is a problem with the software. mod_rewrite has been put
>>>> through the paces over the years and I'd be shocked if a bug were
>>>> uncovered given your rule's relative simplicity.
>>>>
>>>> Before digesting your post in its entirety, I have a couple of
>>>> questions
>>>> first.
>>>>
>>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>>
>>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>>
>>>> 3.) Have you reviewed Apache's access log at all?
>>>>
>>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly what
>>>> the mod_rewrite engine is doing?
>>>>
>>>> -Ben
>>>>
>>>>
>>>>
>>>>> So I'll be very pleased to here from some qualified developer before I
>>>>> spend 2 days to modify and retest all my application.
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> On 07/02/13 11:17, Riccardo Cohen wrote:
>>>>>> Sorry to insist but I'm really blocked and I really need help.
>>>>>> Here is a small summary for those who don't want to read all :
>>>>>>
>>>>>> I want to make a rewrite from :
>>>>>>
>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>> to
>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>
>>>>>> my rewrite rule is
>>>>>>
>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>
>>>>>> This works when apache is runnnig with mod_php, but not when running
>>>>>> mod_fcgid (php as cgi). In cgi mode I have a 404 error.
>>>>>>
>>>>>> The Apache version is 2.2.23 and mod_fcgid is version 2.3.7 with
>>>>>> configuration flag cgi.fix_pathinfo=1
>>>>>>
>>>>>> Thanks for your help.
>>>>>>
>>>>>>
>>>>>> On 05/02/13 21:32, Riccardo Cohen wrote:
>>>>>>> Hello
>>>>>>> I'm new to apache mailing list, sorry if I'm not 100% clear, and
>>>>>>> sorry
>>>>>>> for this long description.
>>>>>>>
>>>>>>> I have developped a website with php/mysql :
>>>>>>> http://www.perspectives-musicales.org and placed it on a good
>>>>>>> hosting
>>>>>>> service (web4all.fr).
>>>>>>> To improve search engine rank I decided to set all urls to
>>>>>>> /index.php/... and rewrite them to avoid having index.php in url
>>>>>>> (sort
>>>>>>> of MVC technique combined with SEO...)
>>>>>>>
>>>>>>> Example : the catalog is at url :
>>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>>> This should be transparantly mapped to
>>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>>> thanks to
>>>>>>> the rewrite rule :
>>>>>>>
>>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>>
>>>>>>> My application uses then $_SERVER["PATH_INFO"] (and not
>>>>>>> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
>>>>>>> perfectly until last month, because web4all.fr changed the whole
>>>>>>> system
>>>>>>> and separated apache from php, using fast cgi instead of mod_php.
>>>>>>>
>>>>>>> The system is supposed to be more reliable and more efficient like
>>>>>>> this,
>>>>>>> and apparently is. But the rewrite rule does not work anymore. So I
>>>>>>> investigated and made some test :
>>>>>>>
>>>>>>> I have a small test.php that displays the path_info and
>>>>>>> query_string.
>>>>>>> You can presently test it here :
>>>>>>>
>>>>>>> http://perspectives-musicales.org/test1/a/b/c
>>>>>>> http://perspectives-musicales.org/test2/a/b/c
>>>>>>> http://perspectives-musicales.org/test3/a/b/c
>>>>>>> http://perspectives-musicales.org/test4/a/b/c
>>>>>>>
>>>>>>> and I set the following rules :
>>>>>>>
>>>>>>> RewriteRule ^test1/(.*) ./test.php/$1
>>>>>>> RewriteRule ^test2/(.*) ./test.php?$1
>>>>>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>>>>>> RewriteRule ^test4/(.*)
>>>>>>> http://www.perspectives-musicales.org/test.php/$1
>>>>>>>
>>>>>>> None of these 4 rewrite rules are convenient. Here is why :
>>>>>>>
>>>>>>> - test1 : the system anwsers 404 "No input file specified". I think
>>>>>>> (not
>>>>>>> sure) that Apache beleives that test.php is a folder, and cannot
>>>>>>> find it
>>>>>>> so answers 404
>>>>>>>
>>>>>>> - test2 : the rewrite rule works, but of course the url
>>>>>>> information is
>>>>>>> no more in path_info, it is in query_string as shown in the page
>>>>>>> content
>>>>>>>
>>>>>>> - test3 : same as test2
>>>>>>>
>>>>>>> - test4 : almost good, I can have the url info in path_info, but
>>>>>>> apache
>>>>>>> begins first with a 302 redirection and then changes the url to
>>>>>>> http://www.perspectives-musicales.org/test.php/a/b/c, which
>>>>>>> looses all
>>>>>>> search engine efficiency (and also eventual POST variables if any).
>>>>>>>
>>>>>>> My host tried several searches on forums including this one, and
>>>>>>> could
>>>>>>> not find any answer. It seems to be an apache bug, but not sure, I
>>>>>>> have
>>>>>>> no bug number to give anyway. If it is a bug, it is demontrated by
>>>>>>> test1
>>>>>>> I think.
>>>>>>>
>>>>>>> So here is my question : Is there any way to make this rewrite rule
>>>>>>> work
>>>>>>> in fastcgi mode, and what is the syntax for it, to keep info in
>>>>>>> path_info without 302 redirection. The Apache version is 2.2.23 and
>>>>>>> mod_fcgid is version 2.3.7 with configuration flag
>>>>>>> cgi.fix_pathinfo=1
>>>>>>>
>>>>>>> If there is a way, thanks for your help I'd be glad to test it.
>>>>>>> If no
>>>>>>> could you explain why and how to solve it. As workaround we used
>>>>>>> test4
>>>>>>> syntax in the whole site, to make it work, but it is bad for search
>>>>>>> engine, and creates problem in backoffice (because certain
>>>>>>> backoffice
>>>>>>> functions use POST variables)
>>>>>>>
>>>>>>> I know I can change my code to use query_string everywhere
>>>>>>> instead of
>>>>>>> path_info, but if I can avoid changing and testing all my
>>>>>>> websites it
>>>>>>> would be really great
>>>>>>>
>>>>>>> Thanks a lot for your anwser.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Riccardo Cohen <r....@realty-property.com>.
Hi Ben
I tried without the dot : RewriteRule ^en/(.*) index.php/en/$1 but it
gave also an error 404.
These are all my tests : (available at
http://www.perspectives-musicales.org/test1/a/b/c etc.)
RewriteRule ^test1/(.*) ./test.php/$1
# = error 404
RewriteRule ^test2/(.*) ./test.php?$1
# = parameters are in query_string instead of path_info
RewriteRule ^test3/(.*) ./test.php?/$1
# = parameters are in query_string instead of path_info
RewriteRule ^test4/(.*) http://www.perspectives-musicales.org/test.php/$1
# = redirection 302
RewriteRule ^test5/(.*) test.php/$1
# = error 404
RewriteRule ^test6/(.*) /test.php/$1
# = error 404
I could not find the apache error log, so I'll ask my hosting support
team and get back to you
Thanks for your help.
On 12/02/13 19:40, Ben Johnson wrote:
>
>
> On 2/12/2013 10:59 AM, Riccardo Cohen wrote:
>> Thanks Ben, here are the answers :
>>
>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>
>> in .htaccess
>>
>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>
>> no change with or without
>>
>>> 3.) Have you reviewed Apache's access log at all?
>>
>> I'll have a look now
>>
>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly what
>>> the mod_rewrite engine is doing?
>>
>> I'll try that. Is it possible to set it in .htacces or must I change
>> global apache configuration (I only have access to my .htaccess in this
>> hosting).
>
> Unfortunately, RewriteLogLevel can be set in the "server config" and
> "virtual host" contexts only. (You can make this type of determination
> in the future by visiting the manual page and looking for the "context"
> value:
> http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewriteloglevel .)
>
> This is one of many reasons for which hosting on a VPS over which you
> have complete control is beneficial.
>
> In any case, we'll have to proceed without access to the rewrite log.
>
> Is there a specific reason for which you're using "./index.php" in the
> right-hand side of the rule? I'm referring to the period ("."), in
> particular. This may well be the source of the problem. It could be that
> mod_php interprets that relative path (./index.php) "correctly", whereas
> mod_fcgid does not.
>
> Try this:
>
> RewriteRule ^en/(.*) index.php/en/$1
>
> -Ben
>
>
>
>> Thanks
>>
>> On 12/02/13 14:53, Ben Johnson wrote:
>>>
>>>
>>> On 2/12/2013 2:16 AM, Riccardo Cohen wrote:
>>>> Hello
>>>> I received some clues from this list members, thanks for that. But
>>>> unfortunately my problem is not solved.
>>>>
>>>> It's not that I want others to focus on me, but I'm quite sure that
>>>> there is a real problem (if not why would it work perfectly on mod_php
>>>> ?), I could not find any solution googling about it (even with the help
>>>> of the host technical team), and I would like a confirmation that 1)
>>>> it's not an error from my understanding, and 2) there is no workaround
>>>> for it.
>>>
>>> I doubt it is a problem with the software. mod_rewrite has been put
>>> through the paces over the years and I'd be shocked if a bug were
>>> uncovered given your rule's relative simplicity.
>>>
>>> Before digesting your post in its entirety, I have a couple of questions
>>> first.
>>>
>>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>>
>>> 2.) Have you defined a RewriteBase? If so, what is it?
>>>
>>> 3.) Have you reviewed Apache's access log at all?
>>>
>>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly what
>>> the mod_rewrite engine is doing?
>>>
>>> -Ben
>>>
>>>
>>>
>>>> So I'll be very pleased to here from some qualified developer before I
>>>> spend 2 days to modify and retest all my application.
>>>>
>>>> Thanks in advance.
>>>>
>>>> On 07/02/13 11:17, Riccardo Cohen wrote:
>>>>> Sorry to insist but I'm really blocked and I really need help.
>>>>> Here is a small summary for those who don't want to read all :
>>>>>
>>>>> I want to make a rewrite from :
>>>>>
>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>> to
>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>
>>>>> my rewrite rule is
>>>>>
>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>
>>>>> This works when apache is runnnig with mod_php, but not when running
>>>>> mod_fcgid (php as cgi). In cgi mode I have a 404 error.
>>>>>
>>>>> The Apache version is 2.2.23 and mod_fcgid is version 2.3.7 with
>>>>> configuration flag cgi.fix_pathinfo=1
>>>>>
>>>>> Thanks for your help.
>>>>>
>>>>>
>>>>> On 05/02/13 21:32, Riccardo Cohen wrote:
>>>>>> Hello
>>>>>> I'm new to apache mailing list, sorry if I'm not 100% clear, and sorry
>>>>>> for this long description.
>>>>>>
>>>>>> I have developped a website with php/mysql :
>>>>>> http://www.perspectives-musicales.org and placed it on a good hosting
>>>>>> service (web4all.fr).
>>>>>> To improve search engine rank I decided to set all urls to
>>>>>> /index.php/... and rewrite them to avoid having index.php in url (sort
>>>>>> of MVC technique combined with SEO...)
>>>>>>
>>>>>> Example : the catalog is at url :
>>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>>> This should be transparantly mapped to
>>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>>> thanks to
>>>>>> the rewrite rule :
>>>>>>
>>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>>
>>>>>> My application uses then $_SERVER["PATH_INFO"] (and not
>>>>>> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
>>>>>> perfectly until last month, because web4all.fr changed the whole
>>>>>> system
>>>>>> and separated apache from php, using fast cgi instead of mod_php.
>>>>>>
>>>>>> The system is supposed to be more reliable and more efficient like
>>>>>> this,
>>>>>> and apparently is. But the rewrite rule does not work anymore. So I
>>>>>> investigated and made some test :
>>>>>>
>>>>>> I have a small test.php that displays the path_info and query_string.
>>>>>> You can presently test it here :
>>>>>>
>>>>>> http://perspectives-musicales.org/test1/a/b/c
>>>>>> http://perspectives-musicales.org/test2/a/b/c
>>>>>> http://perspectives-musicales.org/test3/a/b/c
>>>>>> http://perspectives-musicales.org/test4/a/b/c
>>>>>>
>>>>>> and I set the following rules :
>>>>>>
>>>>>> RewriteRule ^test1/(.*) ./test.php/$1
>>>>>> RewriteRule ^test2/(.*) ./test.php?$1
>>>>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>>>>> RewriteRule ^test4/(.*)
>>>>>> http://www.perspectives-musicales.org/test.php/$1
>>>>>>
>>>>>> None of these 4 rewrite rules are convenient. Here is why :
>>>>>>
>>>>>> - test1 : the system anwsers 404 "No input file specified". I think
>>>>>> (not
>>>>>> sure) that Apache beleives that test.php is a folder, and cannot
>>>>>> find it
>>>>>> so answers 404
>>>>>>
>>>>>> - test2 : the rewrite rule works, but of course the url information is
>>>>>> no more in path_info, it is in query_string as shown in the page
>>>>>> content
>>>>>>
>>>>>> - test3 : same as test2
>>>>>>
>>>>>> - test4 : almost good, I can have the url info in path_info, but
>>>>>> apache
>>>>>> begins first with a 302 redirection and then changes the url to
>>>>>> http://www.perspectives-musicales.org/test.php/a/b/c, which looses all
>>>>>> search engine efficiency (and also eventual POST variables if any).
>>>>>>
>>>>>> My host tried several searches on forums including this one, and could
>>>>>> not find any answer. It seems to be an apache bug, but not sure, I
>>>>>> have
>>>>>> no bug number to give anyway. If it is a bug, it is demontrated by
>>>>>> test1
>>>>>> I think.
>>>>>>
>>>>>> So here is my question : Is there any way to make this rewrite rule
>>>>>> work
>>>>>> in fastcgi mode, and what is the syntax for it, to keep info in
>>>>>> path_info without 302 redirection. The Apache version is 2.2.23 and
>>>>>> mod_fcgid is version 2.3.7 with configuration flag cgi.fix_pathinfo=1
>>>>>>
>>>>>> If there is a way, thanks for your help I'd be glad to test it. If no
>>>>>> could you explain why and how to solve it. As workaround we used test4
>>>>>> syntax in the whole site, to make it work, but it is bad for search
>>>>>> engine, and creates problem in backoffice (because certain backoffice
>>>>>> functions use POST variables)
>>>>>>
>>>>>> I know I can change my code to use query_string everywhere instead of
>>>>>> path_info, but if I can avoid changing and testing all my websites it
>>>>>> would be really great
>>>>>>
>>>>>> Thanks a lot for your anwser.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
--
Riccardo Cohen
+33 (0)6 09 83 64 49
Société Realty-Property.com
1 rue de la Monnaie
37000 Tours
France
<http://www.appartement-maison.fr>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Ben Johnson <be...@indietorrent.org>.
On 2/12/2013 10:59 AM, Riccardo Cohen wrote:
> Thanks Ben, here are the answers :
>
>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>
> in .htaccess
>
>> 2.) Have you defined a RewriteBase? If so, what is it?
>
> no change with or without
>
>> 3.) Have you reviewed Apache's access log at all?
>
> I'll have a look now
>
>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly what
>> the mod_rewrite engine is doing?
>
> I'll try that. Is it possible to set it in .htacces or must I change
> global apache configuration (I only have access to my .htaccess in this
> hosting).
Unfortunately, RewriteLogLevel can be set in the "server config" and
"virtual host" contexts only. (You can make this type of determination
in the future by visiting the manual page and looking for the "context"
value:
http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewriteloglevel .)
This is one of many reasons for which hosting on a VPS over which you
have complete control is beneficial.
In any case, we'll have to proceed without access to the rewrite log.
Is there a specific reason for which you're using "./index.php" in the
right-hand side of the rule? I'm referring to the period ("."), in
particular. This may well be the source of the problem. It could be that
mod_php interprets that relative path (./index.php) "correctly", whereas
mod_fcgid does not.
Try this:
RewriteRule ^en/(.*) index.php/en/$1
-Ben
> Thanks
>
> On 12/02/13 14:53, Ben Johnson wrote:
>>
>>
>> On 2/12/2013 2:16 AM, Riccardo Cohen wrote:
>>> Hello
>>> I received some clues from this list members, thanks for that. But
>>> unfortunately my problem is not solved.
>>>
>>> It's not that I want others to focus on me, but I'm quite sure that
>>> there is a real problem (if not why would it work perfectly on mod_php
>>> ?), I could not find any solution googling about it (even with the help
>>> of the host technical team), and I would like a confirmation that 1)
>>> it's not an error from my understanding, and 2) there is no workaround
>>> for it.
>>
>> I doubt it is a problem with the software. mod_rewrite has been put
>> through the paces over the years and I'd be shocked if a bug were
>> uncovered given your rule's relative simplicity.
>>
>> Before digesting your post in its entirety, I have a couple of questions
>> first.
>>
>> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>>
>> 2.) Have you defined a RewriteBase? If so, what is it?
>>
>> 3.) Have you reviewed Apache's access log at all?
>>
>> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly what
>> the mod_rewrite engine is doing?
>>
>> -Ben
>>
>>
>>
>>> So I'll be very pleased to here from some qualified developer before I
>>> spend 2 days to modify and retest all my application.
>>>
>>> Thanks in advance.
>>>
>>> On 07/02/13 11:17, Riccardo Cohen wrote:
>>>> Sorry to insist but I'm really blocked and I really need help.
>>>> Here is a small summary for those who don't want to read all :
>>>>
>>>> I want to make a rewrite from :
>>>>
>>>> http://www.perspectives-musicales.org/en/all-albums
>>>> to
>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>
>>>> my rewrite rule is
>>>>
>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>
>>>> This works when apache is runnnig with mod_php, but not when running
>>>> mod_fcgid (php as cgi). In cgi mode I have a 404 error.
>>>>
>>>> The Apache version is 2.2.23 and mod_fcgid is version 2.3.7 with
>>>> configuration flag cgi.fix_pathinfo=1
>>>>
>>>> Thanks for your help.
>>>>
>>>>
>>>> On 05/02/13 21:32, Riccardo Cohen wrote:
>>>>> Hello
>>>>> I'm new to apache mailing list, sorry if I'm not 100% clear, and sorry
>>>>> for this long description.
>>>>>
>>>>> I have developped a website with php/mysql :
>>>>> http://www.perspectives-musicales.org and placed it on a good hosting
>>>>> service (web4all.fr).
>>>>> To improve search engine rank I decided to set all urls to
>>>>> /index.php/... and rewrite them to avoid having index.php in url (sort
>>>>> of MVC technique combined with SEO...)
>>>>>
>>>>> Example : the catalog is at url :
>>>>> http://www.perspectives-musicales.org/en/all-albums
>>>>> This should be transparantly mapped to
>>>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>>> thanks to
>>>>> the rewrite rule :
>>>>>
>>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>>
>>>>> My application uses then $_SERVER["PATH_INFO"] (and not
>>>>> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
>>>>> perfectly until last month, because web4all.fr changed the whole
>>>>> system
>>>>> and separated apache from php, using fast cgi instead of mod_php.
>>>>>
>>>>> The system is supposed to be more reliable and more efficient like
>>>>> this,
>>>>> and apparently is. But the rewrite rule does not work anymore. So I
>>>>> investigated and made some test :
>>>>>
>>>>> I have a small test.php that displays the path_info and query_string.
>>>>> You can presently test it here :
>>>>>
>>>>> http://perspectives-musicales.org/test1/a/b/c
>>>>> http://perspectives-musicales.org/test2/a/b/c
>>>>> http://perspectives-musicales.org/test3/a/b/c
>>>>> http://perspectives-musicales.org/test4/a/b/c
>>>>>
>>>>> and I set the following rules :
>>>>>
>>>>> RewriteRule ^test1/(.*) ./test.php/$1
>>>>> RewriteRule ^test2/(.*) ./test.php?$1
>>>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>>>> RewriteRule ^test4/(.*)
>>>>> http://www.perspectives-musicales.org/test.php/$1
>>>>>
>>>>> None of these 4 rewrite rules are convenient. Here is why :
>>>>>
>>>>> - test1 : the system anwsers 404 "No input file specified". I think
>>>>> (not
>>>>> sure) that Apache beleives that test.php is a folder, and cannot
>>>>> find it
>>>>> so answers 404
>>>>>
>>>>> - test2 : the rewrite rule works, but of course the url information is
>>>>> no more in path_info, it is in query_string as shown in the page
>>>>> content
>>>>>
>>>>> - test3 : same as test2
>>>>>
>>>>> - test4 : almost good, I can have the url info in path_info, but
>>>>> apache
>>>>> begins first with a 302 redirection and then changes the url to
>>>>> http://www.perspectives-musicales.org/test.php/a/b/c, which looses all
>>>>> search engine efficiency (and also eventual POST variables if any).
>>>>>
>>>>> My host tried several searches on forums including this one, and could
>>>>> not find any answer. It seems to be an apache bug, but not sure, I
>>>>> have
>>>>> no bug number to give anyway. If it is a bug, it is demontrated by
>>>>> test1
>>>>> I think.
>>>>>
>>>>> So here is my question : Is there any way to make this rewrite rule
>>>>> work
>>>>> in fastcgi mode, and what is the syntax for it, to keep info in
>>>>> path_info without 302 redirection. The Apache version is 2.2.23 and
>>>>> mod_fcgid is version 2.3.7 with configuration flag cgi.fix_pathinfo=1
>>>>>
>>>>> If there is a way, thanks for your help I'd be glad to test it. If no
>>>>> could you explain why and how to solve it. As workaround we used test4
>>>>> syntax in the whole site, to make it work, but it is bad for search
>>>>> engine, and creates problem in backoffice (because certain backoffice
>>>>> functions use POST variables)
>>>>>
>>>>> I know I can change my code to use query_string everywhere instead of
>>>>> path_info, but if I can avoid changing and testing all my websites it
>>>>> would be really great
>>>>>
>>>>> Thanks a lot for your anwser.
>>>>>
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Riccardo Cohen <r....@realty-property.com>.
Thanks Ben, here are the answers :
> 1.) Where have you defined the rewrite rule? In a .htaccess file?
in .htaccess
> 2.) Have you defined a RewriteBase? If so, what is it?
no change with or without
> 3.) Have you reviewed Apache's access log at all?
I'll have a look now
> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly what
> the mod_rewrite engine is doing?
I'll try that. Is it possible to set it in .htacces or must I change
global apache configuration (I only have access to my .htaccess in this
hosting).
Thanks
On 12/02/13 14:53, Ben Johnson wrote:
>
>
> On 2/12/2013 2:16 AM, Riccardo Cohen wrote:
>> Hello
>> I received some clues from this list members, thanks for that. But
>> unfortunately my problem is not solved.
>>
>> It's not that I want others to focus on me, but I'm quite sure that
>> there is a real problem (if not why would it work perfectly on mod_php
>> ?), I could not find any solution googling about it (even with the help
>> of the host technical team), and I would like a confirmation that 1)
>> it's not an error from my understanding, and 2) there is no workaround
>> for it.
>
> I doubt it is a problem with the software. mod_rewrite has been put
> through the paces over the years and I'd be shocked if a bug were
> uncovered given your rule's relative simplicity.
>
> Before digesting your post in its entirety, I have a couple of questions
> first.
>
> 1.) Where have you defined the rewrite rule? In a .htaccess file?
>
> 2.) Have you defined a RewriteBase? If so, what is it?
>
> 3.) Have you reviewed Apache's access log at all?
>
> 4.) Have you increased RewriteLogLevel to, say, 4, to see exactly what
> the mod_rewrite engine is doing?
>
> -Ben
>
>
>
>> So I'll be very pleased to here from some qualified developer before I
>> spend 2 days to modify and retest all my application.
>>
>> Thanks in advance.
>>
>> On 07/02/13 11:17, Riccardo Cohen wrote:
>>> Sorry to insist but I'm really blocked and I really need help.
>>> Here is a small summary for those who don't want to read all :
>>>
>>> I want to make a rewrite from :
>>>
>>> http://www.perspectives-musicales.org/en/all-albums
>>> to
>>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>>
>>> my rewrite rule is
>>>
>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>
>>> This works when apache is runnnig with mod_php, but not when running
>>> mod_fcgid (php as cgi). In cgi mode I have a 404 error.
>>>
>>> The Apache version is 2.2.23 and mod_fcgid is version 2.3.7 with
>>> configuration flag cgi.fix_pathinfo=1
>>>
>>> Thanks for your help.
>>>
>>>
>>> On 05/02/13 21:32, Riccardo Cohen wrote:
>>>> Hello
>>>> I'm new to apache mailing list, sorry if I'm not 100% clear, and sorry
>>>> for this long description.
>>>>
>>>> I have developped a website with php/mysql :
>>>> http://www.perspectives-musicales.org and placed it on a good hosting
>>>> service (web4all.fr).
>>>> To improve search engine rank I decided to set all urls to
>>>> /index.php/... and rewrite them to avoid having index.php in url (sort
>>>> of MVC technique combined with SEO...)
>>>>
>>>> Example : the catalog is at url :
>>>> http://www.perspectives-musicales.org/en/all-albums
>>>> This should be transparantly mapped to
>>>> http://www.perspectives-musicales.org/index.php/en/all-albums thanks to
>>>> the rewrite rule :
>>>>
>>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>>
>>>> My application uses then $_SERVER["PATH_INFO"] (and not
>>>> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
>>>> perfectly until last month, because web4all.fr changed the whole system
>>>> and separated apache from php, using fast cgi instead of mod_php.
>>>>
>>>> The system is supposed to be more reliable and more efficient like this,
>>>> and apparently is. But the rewrite rule does not work anymore. So I
>>>> investigated and made some test :
>>>>
>>>> I have a small test.php that displays the path_info and query_string.
>>>> You can presently test it here :
>>>>
>>>> http://perspectives-musicales.org/test1/a/b/c
>>>> http://perspectives-musicales.org/test2/a/b/c
>>>> http://perspectives-musicales.org/test3/a/b/c
>>>> http://perspectives-musicales.org/test4/a/b/c
>>>>
>>>> and I set the following rules :
>>>>
>>>> RewriteRule ^test1/(.*) ./test.php/$1
>>>> RewriteRule ^test2/(.*) ./test.php?$1
>>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>>> RewriteRule ^test4/(.*)
>>>> http://www.perspectives-musicales.org/test.php/$1
>>>>
>>>> None of these 4 rewrite rules are convenient. Here is why :
>>>>
>>>> - test1 : the system anwsers 404 "No input file specified". I think (not
>>>> sure) that Apache beleives that test.php is a folder, and cannot find it
>>>> so answers 404
>>>>
>>>> - test2 : the rewrite rule works, but of course the url information is
>>>> no more in path_info, it is in query_string as shown in the page content
>>>>
>>>> - test3 : same as test2
>>>>
>>>> - test4 : almost good, I can have the url info in path_info, but apache
>>>> begins first with a 302 redirection and then changes the url to
>>>> http://www.perspectives-musicales.org/test.php/a/b/c, which looses all
>>>> search engine efficiency (and also eventual POST variables if any).
>>>>
>>>> My host tried several searches on forums including this one, and could
>>>> not find any answer. It seems to be an apache bug, but not sure, I have
>>>> no bug number to give anyway. If it is a bug, it is demontrated by test1
>>>> I think.
>>>>
>>>> So here is my question : Is there any way to make this rewrite rule work
>>>> in fastcgi mode, and what is the syntax for it, to keep info in
>>>> path_info without 302 redirection. The Apache version is 2.2.23 and
>>>> mod_fcgid is version 2.3.7 with configuration flag cgi.fix_pathinfo=1
>>>>
>>>> If there is a way, thanks for your help I'd be glad to test it. If no
>>>> could you explain why and how to solve it. As workaround we used test4
>>>> syntax in the whole site, to make it work, but it is bad for search
>>>> engine, and creates problem in backoffice (because certain backoffice
>>>> functions use POST variables)
>>>>
>>>> I know I can change my code to use query_string everywhere instead of
>>>> path_info, but if I can avoid changing and testing all my websites it
>>>> would be really great
>>>>
>>>> Thanks a lot for your anwser.
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
--
Riccardo Cohen
+33 (0)6 09 83 64 49
Société Realty-Property.com
1 rue de la Monnaie
37000 Tours
France
<http://www.appartement-maison.fr>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Ben Johnson <be...@indietorrent.org>.
On 2/12/2013 2:16 AM, Riccardo Cohen wrote:
> Hello
> I received some clues from this list members, thanks for that. But
> unfortunately my problem is not solved.
>
> It's not that I want others to focus on me, but I'm quite sure that
> there is a real problem (if not why would it work perfectly on mod_php
> ?), I could not find any solution googling about it (even with the help
> of the host technical team), and I would like a confirmation that 1)
> it's not an error from my understanding, and 2) there is no workaround
> for it.
I doubt it is a problem with the software. mod_rewrite has been put
through the paces over the years and I'd be shocked if a bug were
uncovered given your rule's relative simplicity.
Before digesting your post in its entirety, I have a couple of questions
first.
1.) Where have you defined the rewrite rule? In a .htaccess file?
2.) Have you defined a RewriteBase? If so, what is it?
3.) Have you reviewed Apache's access log at all?
4.) Have you increased RewriteLogLevel to, say, 4, to see exactly what
the mod_rewrite engine is doing?
-Ben
> So I'll be very pleased to here from some qualified developer before I
> spend 2 days to modify and retest all my application.
>
> Thanks in advance.
>
> On 07/02/13 11:17, Riccardo Cohen wrote:
>> Sorry to insist but I'm really blocked and I really need help.
>> Here is a small summary for those who don't want to read all :
>>
>> I want to make a rewrite from :
>>
>> http://www.perspectives-musicales.org/en/all-albums
>> to
>> http://www.perspectives-musicales.org/index.php/en/all-albums
>>
>> my rewrite rule is
>>
>> RewriteRule ^en/(.*) ./index.php/en/$1
>>
>> This works when apache is runnnig with mod_php, but not when running
>> mod_fcgid (php as cgi). In cgi mode I have a 404 error.
>>
>> The Apache version is 2.2.23 and mod_fcgid is version 2.3.7 with
>> configuration flag cgi.fix_pathinfo=1
>>
>> Thanks for your help.
>>
>>
>> On 05/02/13 21:32, Riccardo Cohen wrote:
>>> Hello
>>> I'm new to apache mailing list, sorry if I'm not 100% clear, and sorry
>>> for this long description.
>>>
>>> I have developped a website with php/mysql :
>>> http://www.perspectives-musicales.org and placed it on a good hosting
>>> service (web4all.fr).
>>> To improve search engine rank I decided to set all urls to
>>> /index.php/... and rewrite them to avoid having index.php in url (sort
>>> of MVC technique combined with SEO...)
>>>
>>> Example : the catalog is at url :
>>> http://www.perspectives-musicales.org/en/all-albums
>>> This should be transparantly mapped to
>>> http://www.perspectives-musicales.org/index.php/en/all-albums thanks to
>>> the rewrite rule :
>>>
>>> RewriteRule ^en/(.*) ./index.php/en/$1
>>>
>>> My application uses then $_SERVER["PATH_INFO"] (and not
>>> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
>>> perfectly until last month, because web4all.fr changed the whole system
>>> and separated apache from php, using fast cgi instead of mod_php.
>>>
>>> The system is supposed to be more reliable and more efficient like this,
>>> and apparently is. But the rewrite rule does not work anymore. So I
>>> investigated and made some test :
>>>
>>> I have a small test.php that displays the path_info and query_string.
>>> You can presently test it here :
>>>
>>> http://perspectives-musicales.org/test1/a/b/c
>>> http://perspectives-musicales.org/test2/a/b/c
>>> http://perspectives-musicales.org/test3/a/b/c
>>> http://perspectives-musicales.org/test4/a/b/c
>>>
>>> and I set the following rules :
>>>
>>> RewriteRule ^test1/(.*) ./test.php/$1
>>> RewriteRule ^test2/(.*) ./test.php?$1
>>> RewriteRule ^test3/(.*) ./test.php?/$1
>>> RewriteRule ^test4/(.*)
>>> http://www.perspectives-musicales.org/test.php/$1
>>>
>>> None of these 4 rewrite rules are convenient. Here is why :
>>>
>>> - test1 : the system anwsers 404 "No input file specified". I think (not
>>> sure) that Apache beleives that test.php is a folder, and cannot find it
>>> so answers 404
>>>
>>> - test2 : the rewrite rule works, but of course the url information is
>>> no more in path_info, it is in query_string as shown in the page content
>>>
>>> - test3 : same as test2
>>>
>>> - test4 : almost good, I can have the url info in path_info, but apache
>>> begins first with a 302 redirection and then changes the url to
>>> http://www.perspectives-musicales.org/test.php/a/b/c, which looses all
>>> search engine efficiency (and also eventual POST variables if any).
>>>
>>> My host tried several searches on forums including this one, and could
>>> not find any answer. It seems to be an apache bug, but not sure, I have
>>> no bug number to give anyway. If it is a bug, it is demontrated by test1
>>> I think.
>>>
>>> So here is my question : Is there any way to make this rewrite rule work
>>> in fastcgi mode, and what is the syntax for it, to keep info in
>>> path_info without 302 redirection. The Apache version is 2.2.23 and
>>> mod_fcgid is version 2.3.7 with configuration flag cgi.fix_pathinfo=1
>>>
>>> If there is a way, thanks for your help I'd be glad to test it. If no
>>> could you explain why and how to solve it. As workaround we used test4
>>> syntax in the whole site, to make it work, but it is bad for search
>>> engine, and creates problem in backoffice (because certain backoffice
>>> functions use POST variables)
>>>
>>> I know I can change my code to use query_string everywhere instead of
>>> path_info, but if I can avoid changing and testing all my websites it
>>> would be really great
>>>
>>> Thanks a lot for your anwser.
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Riccardo Cohen <r....@realty-property.com>.
Hello
I received some clues from this list members, thanks for that. But
unfortunately my problem is not solved.
It's not that I want others to focus on me, but I'm quite sure that
there is a real problem (if not why would it work perfectly on mod_php
?), I could not find any solution googling about it (even with the help
of the host technical team), and I would like a confirmation that 1)
it's not an error from my understanding, and 2) there is no workaround
for it.
So I'll be very pleased to here from some qualified developer before I
spend 2 days to modify and retest all my application.
Thanks in advance.
On 07/02/13 11:17, Riccardo Cohen wrote:
> Sorry to insist but I'm really blocked and I really need help.
> Here is a small summary for those who don't want to read all :
>
> I want to make a rewrite from :
>
> http://www.perspectives-musicales.org/en/all-albums
> to
> http://www.perspectives-musicales.org/index.php/en/all-albums
>
> my rewrite rule is
>
> RewriteRule ^en/(.*) ./index.php/en/$1
>
> This works when apache is runnnig with mod_php, but not when running
> mod_fcgid (php as cgi). In cgi mode I have a 404 error.
>
> The Apache version is 2.2.23 and mod_fcgid is version 2.3.7 with
> configuration flag cgi.fix_pathinfo=1
>
> Thanks for your help.
>
>
> On 05/02/13 21:32, Riccardo Cohen wrote:
>> Hello
>> I'm new to apache mailing list, sorry if I'm not 100% clear, and sorry
>> for this long description.
>>
>> I have developped a website with php/mysql :
>> http://www.perspectives-musicales.org and placed it on a good hosting
>> service (web4all.fr).
>> To improve search engine rank I decided to set all urls to
>> /index.php/... and rewrite them to avoid having index.php in url (sort
>> of MVC technique combined with SEO...)
>>
>> Example : the catalog is at url :
>> http://www.perspectives-musicales.org/en/all-albums
>> This should be transparantly mapped to
>> http://www.perspectives-musicales.org/index.php/en/all-albums thanks to
>> the rewrite rule :
>>
>> RewriteRule ^en/(.*) ./index.php/en/$1
>>
>> My application uses then $_SERVER["PATH_INFO"] (and not
>> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
>> perfectly until last month, because web4all.fr changed the whole system
>> and separated apache from php, using fast cgi instead of mod_php.
>>
>> The system is supposed to be more reliable and more efficient like this,
>> and apparently is. But the rewrite rule does not work anymore. So I
>> investigated and made some test :
>>
>> I have a small test.php that displays the path_info and query_string.
>> You can presently test it here :
>>
>> http://perspectives-musicales.org/test1/a/b/c
>> http://perspectives-musicales.org/test2/a/b/c
>> http://perspectives-musicales.org/test3/a/b/c
>> http://perspectives-musicales.org/test4/a/b/c
>>
>> and I set the following rules :
>>
>> RewriteRule ^test1/(.*) ./test.php/$1
>> RewriteRule ^test2/(.*) ./test.php?$1
>> RewriteRule ^test3/(.*) ./test.php?/$1
>> RewriteRule ^test4/(.*) http://www.perspectives-musicales.org/test.php/$1
>>
>> None of these 4 rewrite rules are convenient. Here is why :
>>
>> - test1 : the system anwsers 404 "No input file specified". I think (not
>> sure) that Apache beleives that test.php is a folder, and cannot find it
>> so answers 404
>>
>> - test2 : the rewrite rule works, but of course the url information is
>> no more in path_info, it is in query_string as shown in the page content
>>
>> - test3 : same as test2
>>
>> - test4 : almost good, I can have the url info in path_info, but apache
>> begins first with a 302 redirection and then changes the url to
>> http://www.perspectives-musicales.org/test.php/a/b/c, which looses all
>> search engine efficiency (and also eventual POST variables if any).
>>
>> My host tried several searches on forums including this one, and could
>> not find any answer. It seems to be an apache bug, but not sure, I have
>> no bug number to give anyway. If it is a bug, it is demontrated by test1
>> I think.
>>
>> So here is my question : Is there any way to make this rewrite rule work
>> in fastcgi mode, and what is the syntax for it, to keep info in
>> path_info without 302 redirection. The Apache version is 2.2.23 and
>> mod_fcgid is version 2.3.7 with configuration flag cgi.fix_pathinfo=1
>>
>> If there is a way, thanks for your help I'd be glad to test it. If no
>> could you explain why and how to solve it. As workaround we used test4
>> syntax in the whole site, to make it work, but it is bad for search
>> engine, and creates problem in backoffice (because certain backoffice
>> functions use POST variables)
>>
>> I know I can change my code to use query_string everywhere instead of
>> path_info, but if I can avoid changing and testing all my websites it
>> would be really great
>>
>> Thanks a lot for your anwser.
>>
>>
>
--
Riccardo Cohen
+33 (0)6 09 83 64 49
Société Realty-Property.com
1 rue de la Monnaie
37000 Tours
France
<http://www.appartement-maison.fr>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Posted by Riccardo Cohen <r....@realty-property.com>.
Sorry to insist but I'm really blocked and I really need help.
Here is a small summary for those who don't want to read all :
I want to make a rewrite from :
http://www.perspectives-musicales.org/en/all-albums
to
http://www.perspectives-musicales.org/index.php/en/all-albums
my rewrite rule is
RewriteRule ^en/(.*) ./index.php/en/$1
This works when apache is runnnig with mod_php, but not when running
mod_fcgid (php as cgi). In cgi mode I have a 404 error.
The Apache version is 2.2.23 and mod_fcgid is version 2.3.7 with
configuration flag cgi.fix_pathinfo=1
Thanks for your help.
On 05/02/13 21:32, Riccardo Cohen wrote:
> Hello
> I'm new to apache mailing list, sorry if I'm not 100% clear, and sorry
> for this long description.
>
> I have developped a website with php/mysql :
> http://www.perspectives-musicales.org and placed it on a good hosting
> service (web4all.fr).
> To improve search engine rank I decided to set all urls to
> /index.php/... and rewrite them to avoid having index.php in url (sort
> of MVC technique combined with SEO...)
>
> Example : the catalog is at url :
> http://www.perspectives-musicales.org/en/all-albums
> This should be transparantly mapped to
> http://www.perspectives-musicales.org/index.php/en/all-albums thanks to
> the rewrite rule :
>
> RewriteRule ^en/(.*) ./index.php/en/$1
>
> My application uses then $_SERVER["PATH_INFO"] (and not
> $_SERVER["QUERY_STRING"]) to retreive url information. This worked
> perfectly until last month, because web4all.fr changed the whole system
> and separated apache from php, using fast cgi instead of mod_php.
>
> The system is supposed to be more reliable and more efficient like this,
> and apparently is. But the rewrite rule does not work anymore. So I
> investigated and made some test :
>
> I have a small test.php that displays the path_info and query_string.
> You can presently test it here :
>
> http://perspectives-musicales.org/test1/a/b/c
> http://perspectives-musicales.org/test2/a/b/c
> http://perspectives-musicales.org/test3/a/b/c
> http://perspectives-musicales.org/test4/a/b/c
>
> and I set the following rules :
>
> RewriteRule ^test1/(.*) ./test.php/$1
> RewriteRule ^test2/(.*) ./test.php?$1
> RewriteRule ^test3/(.*) ./test.php?/$1
> RewriteRule ^test4/(.*) http://www.perspectives-musicales.org/test.php/$1
>
> None of these 4 rewrite rules are convenient. Here is why :
>
> - test1 : the system anwsers 404 "No input file specified". I think (not
> sure) that Apache beleives that test.php is a folder, and cannot find it
> so answers 404
>
> - test2 : the rewrite rule works, but of course the url information is
> no more in path_info, it is in query_string as shown in the page content
>
> - test3 : same as test2
>
> - test4 : almost good, I can have the url info in path_info, but apache
> begins first with a 302 redirection and then changes the url to
> http://www.perspectives-musicales.org/test.php/a/b/c, which looses all
> search engine efficiency (and also eventual POST variables if any).
>
> My host tried several searches on forums including this one, and could
> not find any answer. It seems to be an apache bug, but not sure, I have
> no bug number to give anyway. If it is a bug, it is demontrated by test1
> I think.
>
> So here is my question : Is there any way to make this rewrite rule work
> in fastcgi mode, and what is the syntax for it, to keep info in
> path_info without 302 redirection. The Apache version is 2.2.23 and
> mod_fcgid is version 2.3.7 with configuration flag cgi.fix_pathinfo=1
>
> If there is a way, thanks for your help I'd be glad to test it. If no
> could you explain why and how to solve it. As workaround we used test4
> syntax in the whole site, to make it work, but it is bad for search
> engine, and creates problem in backoffice (because certain backoffice
> functions use POST variables)
>
> I know I can change my code to use query_string everywhere instead of
> path_info, but if I can avoid changing and testing all my websites it
> would be really great
>
> Thanks a lot for your anwser.
>
>
--
Riccardo Cohen
+33 (0)6 09 83 64 49
Société Realty-Property.com
1 rue de la Monnaie
37000 Tours
France
<http://www.appartement-maison.fr>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org