httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Johnson <...@indietorrent.org>
Subject Re: [users@httpd] moving from mod_php to mod_fcgid : rewrite problem
Date Thu, 14 Feb 2013 20:38:25 GMT


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" <ben@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


Mime
View raw message