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.
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....
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 :/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.
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:
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.
Posts: 32509
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.
Posts: 33
sorry, my mistake
Posts: 60
Valiant thanks for the info
Posts: 3
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:
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:
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
Posts: 60
a1r
What are you running on OS version, PHP version, MySQL version, etc....
Posts: 32509
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?
Posts: 3
lupar_blackice, basic info:
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.
I note "Operation timed out" is not the same as 'connection refused'... I'm not 100% sure what's failing here.
- Aaron
Posts: 60
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
Posts: 32509
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:
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?
Posts: 60
So what should I do to get it working?
Posts: 32509
you? deactivate the checks in G2 in your code until G2 has better mod_rewrite checks.
i hope pelle can work on it soon...
Posts: 389
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.
Posts: 389
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.
Posts: 60
cool
Posts: 389
Its in. Get tonights snapshot, module version 0.9.11.
Posts: 3
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.