URL Rewrite problem

valiant

Joined: 2003-01-04
Posts: 32509

Posted: Thu, 2005-06-02 08:44

no, it won't be listed in phpinfo in all cases. this is only true for mod_php, but not for php-cgi and i guess not for php-cgi / fast-cgi either.

RobFerrer

Joined: 2005-03-10
Posts: 33

Posted: Thu, 2005-06-02 08:46

sorry, my mistake

lupar_blackice

Joined: 2005-04-21
Posts: 60

Posted: Thu, 2005-06-02 11:47

Quote:

no, it won't be listed in phpinfo in all cases. this is only true for mod_php, but not for php-cgi and i guess not for php-cgi / fast-cgi either.

Valiant thanks for the info

a1r

Joined: 2005-06-02
Posts: 3

Posted: Thu, 2005-06-02 12:49

I am in the same situation as ChezDude - I am not allowed to activate rewrite, but I have some further information.

- redirection was working fine with Beta 2.
- my .htaccess file is still there from Beta 2 unchanged.
- the fix from sittingduck has no effect.
- through the web, http://aaronbell.org/gallery2/modules/rewrite/test/mod_rewrite/gallery2/Rewrite.txt returns PASS_REWRITE.

I think autodetection was equally broken in Beta 2 and Beta 3, but not allowing an override is what breaks Beta 3.

My debug output on configuring rewrite:

2005-06-02 13:32:03 [a39e2353438f1fdb14bab234dc3434d7] fsockopen(aaronbell.org, 80, , , 1)
2005-06-02 13:32:04 [a39e2353438f1fdb14bab234dc3434d7] Error 60: 'Operation timed out' retrieving http://aaronbell.org/gallery2/modules/rewrite/test/mod_rewrite_no_options/gallery2/Rewrite.txt
2005-06-02 13:32:04 [a39e2353438f1fdb14bab234dc3434d7] fsockopen(aaronbell.org, 80, , , 1)
2005-06-02 13:32:05 [a39e2353438f1fdb14bab234dc3434d7] Error 60: 'Operation timed out' retrieving http://aaronbell.org/gallery2/modules/rewrite/test/mod_rewrite/gallery2/Rewrite.txt

i.e. the server cannot 'see' itself, despite it working perfectly from the web. This is an acknowledged feature in my case - note this section from my webhost's help pages:

Quote:

Some websites have a need to access their own pages. For example, a PHP page on www.example.com might do a form of file "include" by downloading http://www.example.com/path/to/filename.html and inserting the output in the current page. As with the email problem above, this will not work, since the web servers cannot access "themselves" via the load balancer.

To resolve this, we recommend you append .web-internal.gradwell.net to the hostname in your URL. The example above would therefore become http://www.example.com.web-internal.gradwell.net/path/to/filename.html.

In some cases, this is not possible. Some commercial software for example will check which hostname it was accessed as, and if the licence does not allow that hostname, it will refuse to serve the page. There is at present no perfect solution to this problem.

It looks like this autodetect will never work on my kind of server.

Note that both curl and wget run on the server resolve the URL correctly. They must be resolving the URL at a different level than fsockread - perhaps the fsockread needs to be enhanced to do further URL resolution.

Thanks
- Aaron

lupar_blackice

Joined: 2005-04-21
Posts: 60

Posted: Thu, 2005-06-02 16:49

a1r

What are you running on OS version, PHP version, MySQL version, etc....

valiant

Joined: 2003-01-04
Posts: 32509

Posted: Thu, 2005-06-02 16:57

a1r, please read the first post 3 of this topic:
http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=30535&postdays=0&postorder=asc&start=30

does this fix it for you?

a1r

Joined: 2005-06-02
Posts: 3

Posted: Fri, 2005-06-03 10:41

lupar_blackice, basic info:

Gallery version 	 2.0-beta-3
PHP version 	4.3.9 apache
Webserver 	Apache/1.3.29 (Unix) mod_perl/1.29 mod_become/1.3 DAV/1.0.3 PHP/4.3.9 mod_fastcgi/2.4.2
Database 	mysql 4.1.10a
Toolkits 	ImageMagick, NetPBM, Gd
Operating system 	FreeBSD lon-web-4.gradwell.net 5.3-STABLE FreeBSD 5.3-STABLE #3: Mon Jan 24 13:07:15 GMT 2005 root@lon-web-4.gradwell.net:/usr/obj/usr/src/sys/LONWEB4-20041115 i386
Browser 	Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

valiant, the "sittingduck" fix does not fix the problem. The hostname does appear to be converted into an IP though, in the fsockopen() if not the error message itself.

The debug trace below shows the difference with sittingduck's change in place.

2005-06-03 11:33:01 [a39e2353438f1fdb14bab234dc3434d7] fsockopen(193.111.200.151, 80, , , 1)
2005-06-03 11:33:02 [a39e2353438f1fdb14bab234dc3434d7] Error 60: 'Operation timed out' retrieving http://aaronbell.org/gallery2/modules/rewrite/test/mod_rewrite_no_options/gallery2/Rewrite.txt
2005-06-03 11:33:02 [a39e2353438f1fdb14bab234dc3434d7] fsockopen(193.111.200.151, 80, , , 1)
2005-06-03 11:33:03 [a39e2353438f1fdb14bab234dc3434d7] Error 60: 'Operation timed out' retrieving http://aaronbell.org/gallery2/modules/rewrite/test/mod_rewrite/gallery2/Rewrite.txt

I note "Operation timed out" is not the same as 'connection refused'... I'm not 100% sure what's failing here.

- Aaron

lupar_blackice

Joined: 2005-04-21
Posts: 60

Posted: Fri, 2005-06-03 11:18

Here is some info from my access.log

192.168.1.22 - - [03/Jun/2005:06:11:41 -0500] "POST /gallery2/main.php HTTP/1.1" 302 - "http://icebox/gallery2/main.php?g2_view=core.SiteAdmin&g2_subView=rewrite.SetupRewrite&g2_navId=x5a0599d8" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
192.168.1.23 - - [03/Jun/2005:06:11:43 -0500] "GET /gallery2/modules/rewrite/test/mod_rewrite_no_options/gallery2/Rewrite.txt HTTP/1.0" 200 14 "-" "-"
192.168.1.23 - - [03/Jun/2005:06:11:43 -0500] "GET /gallery2/modules/rewrite/test/mod_rewrite/gallery2/Rewrite.txt HTTP/1.0" 200 14 "-" "-"
192.168.1.22 - - [03/Jun/2005:06:11:42 -0500] "GET /gallery2/main.php?g2_view=core.SiteAdmin&g2_subView=rewrite.SetupRewrite&g2_navId=x5a0599d8 HTTP/1.1" 200 13031 "http://icebox/gallery2/main.php?g2_view=core.SiteAdmin&g2_subView=rewrite.SetupRewrite&g2_navId=x5a0599d8" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
192.168.1.22 - - [03/Jun/2005:06:11:43 -0500] "GET /gallery2/templates/layout.css HTTP/1.1" 304 - "http://icebox/gallery2/main.php?g2_view=core.SiteAdmin&g2_subView=rewrite.SetupRewrite&g2_navId=x5a0599d8" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
192.168.1.22 - - [03/Jun/2005:06:11:43 -0500] "GET /gallery2/themes/black/theme.css HTTP/1.1" 304 - "http://icebox/gallery2/main.php?g2_view=core.SiteAdmin&g2_subView=rewrite.SetupRewrite&g2_navId=x5a0599d8" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

and the error.log is clean

valiant

Joined: 2003-01-04
Posts: 32509

Posted: Fri, 2005-06-03 11:21

lupar_blackice, i checked how G1 does the mod_rewrite detection. In G2, it has to be a little different, because we have only a single entry file to G2, main.php, which is generally a good thing but complicates the mod_rewrite detection.

pelle, why do you need a RewriteBase in the test/mod_rewrite*/*/.htaccess files?

in G1, this is the mod_rewrite code in the setup/.htaccess file to detect mod_rewrite:

Options +FollowSymLinks
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(index.php)$                       index.php?init_mod_rewrite=1&ampersandbroken=    [QSA]
RewriteRule ^$                                  index.php?init_mod_rewrite=1&ampersandbroken=    [QSA]
</IfModule>

No Rewritebase is needed, so you don't need to offer a custom/gallery/gallery2 case, IMO.

Plus, did you have any luck fixing other detection issues, e.g. with the fsockopen fix?

lupar_blackice

Joined: 2005-04-21
Posts: 60

Posted: Sun, 2005-06-05 15:56

valiant wrote:

lupar_blackice, i checked how G1 does the mod_rewrite detection. In G2, it has to be a little different, because we have only a single entry file to G2, main.php, which is generally a good thing but complicates the mod_rewrite detection.

So what should I do to get it working?

valiant

Joined: 2003-01-04
Posts: 32509

Posted: Sun, 2005-06-05 15:58

you? deactivate the checks in G2 in your code until G2 has better mod_rewrite checks.

i hope pelle can work on it soon...

pelle

Joined: 2004-12-10
Posts: 389

Posted: Wed, 2005-06-08 14:24

Just got back from vaccation. A qiuck answear for you valiant; RewriteBase was added because when bharat tested my module the first time around he needed it. Maybe we need to add a test for that too (like we do with Options +FolloSymlinks). A fix for the fsockopen errors seems unlikely since those are from the OS level.

For those of you who get fsockopen failurese, and the rest of you who *know* mod_rewrite is working (ie by viewing the test page with your browser) I'm gonna add a check box just like /cusom/ installs. (Quick tip for you who is eager to get it to work, don't install Gallery in /gallery2 or /gallery until a fix is in.)

Rather than to add a quick fix I think the whole installation process needs to be redone to be less complicated for
- embedded mode users,
- users where we cant autodetect,
- and enhance the autodetection.

pelle

Joined: 2004-12-10
Posts: 389

Posted: Fri, 2005-06-10 14:34

valiant wrote:

No Rewritebase is needed, so you don't need to offer a custom/gallery/gallery2 case, IMO.

I think we still need to offer the cusomt/gallery/galler2 cases. The RewriteBase is by default set to the physical path, which is fine for most of our users. However, if you for instance want to install Gallery in a /~user directory you need the RewriteBase. If you install Gallery in a custom directory and it is the same as the physical path, the custom test should pass since the RewriteBase directive is commented out.

lupar_blackice

Joined: 2005-04-21
Posts: 60

Posted: Sat, 2005-06-11 01:25

pelle wrote:

and the rest of you who *know* mod_rewrite is working (ie by viewing the test page with your browser) I'm gonna add a check box just like /cusom/ installs.

cool

pelle

Joined: 2004-12-10
Posts: 389

Posted: Sun, 2005-06-12 20:36

Its in. Get tonights snapshot, module version 0.9.11.

a1r

Joined: 2005-06-02
Posts: 3

Posted: Mon, 2005-06-13 18:27

Get the nightly snapshot from the 13th June - this is the first snapshot with URL Rewrite 0.9.11. Do a full upgrade of everything.

Works perfectly for me, check the boxes and Save. Thanks Pelle.

valiant Joined: 2003-01-04 Posts: 32509	Posted: Thu, 2005-06-02 08:44
	no, it won't be listed in phpinfo in all cases. this is only true for mod_php, but not for php-cgi and i guess not for php-cgi / fast-cgi either.

RobFerrer Joined: 2005-03-10 Posts: 33	Posted: Thu, 2005-06-02 08:46
	sorry, my mistake

lupar_blackice Joined: 2005-04-21 Posts: 60	Posted: Thu, 2005-06-02 11:47
	Quote: no, it won't be listed in phpinfo in all cases. this is only true for mod_php, but not for php-cgi and i guess not for php-cgi / fast-cgi either. Valiant thanks for the info

a1r Joined: 2005-06-02 Posts: 3	Posted: Thu, 2005-06-02 12:49
	I am in the same situation as ChezDude - I am not allowed to activate rewrite, but I have some further information. - redirection was working fine with Beta 2. - my .htaccess file is still there from Beta 2 unchanged. - the fix from sittingduck has no effect. - through the web, http://aaronbell.org/gallery2/modules/rewrite/test/mod_rewrite/gallery2/Rewrite.txt returns PASS_REWRITE. I think autodetection was equally broken in Beta 2 and Beta 3, but not allowing an override is what breaks Beta 3. My debug output on configuring rewrite: 2005-06-02 13:32:03 [a39e2353438f1fdb14bab234dc3434d7] fsockopen(aaronbell.org, 80, , , 1) 2005-06-02 13:32:04 [a39e2353438f1fdb14bab234dc3434d7] Error 60: 'Operation timed out' retrieving http://aaronbell.org/gallery2/modules/rewrite/test/mod_rewrite_no_options/gallery2/Rewrite.txt 2005-06-02 13:32:04 [a39e2353438f1fdb14bab234dc3434d7] fsockopen(aaronbell.org, 80, , , 1) 2005-06-02 13:32:05 [a39e2353438f1fdb14bab234dc3434d7] Error 60: 'Operation timed out' retrieving http://aaronbell.org/gallery2/modules/rewrite/test/mod_rewrite/gallery2/Rewrite.txt i.e. the server cannot 'see' itself, despite it working perfectly from the web. This is an acknowledged feature in my case - note this section from my webhost's help pages: Quote: Some websites have a need to access their own pages. For example, a PHP page on www.example.com might do a form of file "include" by downloading http://www.example.com/path/to/filename.html and inserting the output in the current page. As with the email problem above, this will not work, since the web servers cannot access "themselves" via the load balancer. To resolve this, we recommend you append .web-internal.gradwell.net to the hostname in your URL. The example above would therefore become http://www.example.com.web-internal.gradwell.net/path/to/filename.html. In some cases, this is not possible. Some commercial software for example will check which hostname it was accessed as, and if the licence does not allow that hostname, it will refuse to serve the page. There is at present no perfect solution to this problem. It looks like this autodetect will never work on my kind of server. Note that both curl and wget run on the server resolve the URL correctly. They must be resolving the URL at a different level than fsockread - perhaps the fsockread needs to be enhanced to do further URL resolution. Thanks - Aaron

lupar_blackice Joined: 2005-04-21 Posts: 60	Posted: Thu, 2005-06-02 16:49
	a1r What are you running on OS version, PHP version, MySQL version, etc....

valiant Joined: 2003-01-04 Posts: 32509	Posted: Thu, 2005-06-02 16:57
	a1r, please read the first post 3 of this topic: http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=30535&postdays=0&postorder=asc&start=30 does this fix it for you?

a1r Joined: 2005-06-02 Posts: 3	Posted: Fri, 2005-06-03 10:41
	lupar_blackice, basic info: Gallery version 2.0-beta-3 PHP version 4.3.9 apache Webserver Apache/1.3.29 (Unix) mod_perl/1.29 mod_become/1.3 DAV/1.0.3 PHP/4.3.9 mod_fastcgi/2.4.2 Database mysql 4.1.10a Toolkits ImageMagick, NetPBM, Gd Operating system FreeBSD lon-web-4.gradwell.net 5.3-STABLE FreeBSD 5.3-STABLE #3: Mon Jan 24 13:07:15 GMT 2005 root@lon-web-4.gradwell.net:/usr/obj/usr/src/sys/LONWEB4-20041115 i386 Browser Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 valiant, the "sittingduck" fix does not fix the problem. The hostname does appear to be converted into an IP though, in the fsockopen() if not the error message itself. The debug trace below shows the difference with sittingduck's change in place. 2005-06-03 11:33:01 [a39e2353438f1fdb14bab234dc3434d7] fsockopen(193.111.200.151, 80, , , 1) 2005-06-03 11:33:02 [a39e2353438f1fdb14bab234dc3434d7] Error 60: 'Operation timed out' retrieving http://aaronbell.org/gallery2/modules/rewrite/test/mod_rewrite_no_options/gallery2/Rewrite.txt 2005-06-03 11:33:02 [a39e2353438f1fdb14bab234dc3434d7] fsockopen(193.111.200.151, 80, , , 1) 2005-06-03 11:33:03 [a39e2353438f1fdb14bab234dc3434d7] Error 60: 'Operation timed out' retrieving http://aaronbell.org/gallery2/modules/rewrite/test/mod_rewrite/gallery2/Rewrite.txt I note "Operation timed out" is not the same as 'connection refused'... I'm not 100% sure what's failing here. - Aaron

lupar_blackice Joined: 2005-04-21 Posts: 60	Posted: Fri, 2005-06-03 11:18
	Here is some info from my access.log 192.168.1.22 - - [03/Jun/2005:06:11:41 -0500] "POST /gallery2/main.php HTTP/1.1" 302 - "http://icebox/gallery2/main.php?g2_view=core.SiteAdmin&g2_subView=rewrite.SetupRewrite&g2_navId=x5a0599d8" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 192.168.1.23 - - [03/Jun/2005:06:11:43 -0500] "GET /gallery2/modules/rewrite/test/mod_rewrite_no_options/gallery2/Rewrite.txt HTTP/1.0" 200 14 "-" "-" 192.168.1.23 - - [03/Jun/2005:06:11:43 -0500] "GET /gallery2/modules/rewrite/test/mod_rewrite/gallery2/Rewrite.txt HTTP/1.0" 200 14 "-" "-" 192.168.1.22 - - [03/Jun/2005:06:11:42 -0500] "GET /gallery2/main.php?g2_view=core.SiteAdmin&g2_subView=rewrite.SetupRewrite&g2_navId=x5a0599d8 HTTP/1.1" 200 13031 "http://icebox/gallery2/main.php?g2_view=core.SiteAdmin&g2_subView=rewrite.SetupRewrite&g2_navId=x5a0599d8" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 192.168.1.22 - - [03/Jun/2005:06:11:43 -0500] "GET /gallery2/templates/layout.css HTTP/1.1" 304 - "http://icebox/gallery2/main.php?g2_view=core.SiteAdmin&g2_subView=rewrite.SetupRewrite&g2_navId=x5a0599d8" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 192.168.1.22 - - [03/Jun/2005:06:11:43 -0500] "GET /gallery2/themes/black/theme.css HTTP/1.1" 304 - "http://icebox/gallery2/main.php?g2_view=core.SiteAdmin&g2_subView=rewrite.SetupRewrite&g2_navId=x5a0599d8" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" and the error.log is clean

valiant Joined: 2003-01-04 Posts: 32509	Posted: Fri, 2005-06-03 11:21
	lupar_blackice, i checked how G1 does the mod_rewrite detection. In G2, it has to be a little different, because we have only a single entry file to G2, main.php, which is generally a good thing but complicates the mod_rewrite detection. pelle, why do you need a RewriteBase in the test/mod_rewrite//.htaccess files? in G1, this is the mod_rewrite code in the setup/.htaccess file to detect mod_rewrite: Options +FollowSymLinks <IfModule mod_rewrite.c> RewriteEngine On RewriteRule ^(index.php)$ index.php?init_mod_rewrite=1&ampersandbroken= [QSA] RewriteRule ^$ index.php?init_mod_rewrite=1&ampersandbroken= [QSA] </IfModule> No Rewritebase is needed, so you don't need to offer a custom/gallery/gallery2 case, IMO. Plus, did you have any luck fixing other detection issues, e.g. with the fsockopen fix?

lupar_blackice Joined: 2005-04-21 Posts: 60	Posted: Sun, 2005-06-05 15:56
	valiant wrote: lupar_blackice, i checked how G1 does the mod_rewrite detection. In G2, it has to be a little different, because we have only a single entry file to G2, main.php, which is generally a good thing but complicates the mod_rewrite detection. So what should I do to get it working?

valiant Joined: 2003-01-04 Posts: 32509	Posted: Sun, 2005-06-05 15:58
	you? deactivate the checks in G2 in your code until G2 has better mod_rewrite checks. i hope pelle can work on it soon...

pelle Joined: 2004-12-10 Posts: 389	Posted: Wed, 2005-06-08 14:24
	Just got back from vaccation. A qiuck answear for you valiant; RewriteBase was added because when bharat tested my module the first time around he needed it. Maybe we need to add a test for that too (like we do with Options +FolloSymlinks). A fix for the fsockopen errors seems unlikely since those are from the OS level. For those of you who get fsockopen failurese, and the rest of you who know mod_rewrite is working (ie by viewing the test page with your browser) I'm gonna add a check box just like /cusom/ installs. (Quick tip for you who is eager to get it to work, don't install Gallery in /gallery2 or /gallery until a fix is in.) Rather than to add a quick fix I think the whole installation process needs to be redone to be less complicated for - embedded mode users, - users where we cant autodetect, - and enhance the autodetection.

pelle Joined: 2004-12-10 Posts: 389	Posted: Fri, 2005-06-10 14:34
	valiant wrote: No Rewritebase is needed, so you don't need to offer a custom/gallery/gallery2 case, IMO. I think we still need to offer the cusomt/gallery/galler2 cases. The RewriteBase is by default set to the physical path, which is fine for most of our users. However, if you for instance want to install Gallery in a /~user directory you need the RewriteBase. If you install Gallery in a custom directory and it is the same as the physical path, the custom test should pass since the RewriteBase directive is commented out.

lupar_blackice Joined: 2005-04-21 Posts: 60	Posted: Sat, 2005-06-11 01:25
	pelle wrote: and the rest of you who know mod_rewrite is working (ie by viewing the test page with your browser) I'm gonna add a check box just like /cusom/ installs. cool

pelle Joined: 2004-12-10 Posts: 389	Posted: Sun, 2005-06-12 20:36
	Its in. Get tonights snapshot, module version 0.9.11.

a1r Joined: 2005-06-02 Posts: 3	Posted: Mon, 2005-06-13 18:27
	Get the nightly snapshot from the 13th June - this is the first snapshot with URL Rewrite 0.9.11. Do a full upgrade of everything. Works perfectly for me, check the boxes and Save. Thanks Pelle.

« first ‹ previous12