Skip to:
Content

Opened 5 years ago

Closed 3 years ago

Last modified 3 years ago

#1126 closed defect (wontfix)

repermalink fails, causing redirect loop on SunOS (Solaris?), and 404 errors.

Reported by: SteveBooth Owned by:
Milestone: 1.0.3 Priority: high
Severity: major Version:
Component: Front-end Keywords: Sun SunOS Solaris bb_repermalink redirect loop 404 error
Cc:

Description

My web site is hosted on Concentric. Concentric 'Unix' servers appear to be SunOS machines. (You can browse to a phpinfo running on my server here: ( http://stevenmbooth.com/phpinfo.php ) This server provides the following $_SYSTEM variable values when the bb_repermalink routine is invoked from line 5 of index.php in the root directory of bbPress:

REQUEST_URI: (i.e. emptry)
SCRIPT_NAME: '/bbpress/index.php'
PHP_SELF: '/bbpress/index.php'
SERVER_NAME: 'stevenmbooth.com'

The fact that REQUEST_URI is null causes bb_repermalink to generate a 404 error when index.php is invoked (or, obviously, anyone browses to the root for bbPress.)

Concentric is one of the largest hosting platforms, having spun off from Microsoft several years ago. I would think that Sun support would be fairly important to bbPress.

After reviewing a lot of the code in bb_repermalink, my evaluation is that there are numerous assumptions made about the contents of system variables (in particular REQUEST_URI), that the code is insufficiently rigorous about detecting permalinks (it seems to attempt to redirect uri's that could not possibly be permalinks), and generally is going to be a significant problem with cross-platform support in future versions of bbPress.

My recommendation is, first, to install code similar to this (derived from an plugin supplied by _ck_). I coded it at the front of my bb_repermalink, and it helped, but didn't solve all the problems:

	if (isset($_SERVER['REQUEST_URI']))
		$uri = $_SERVER['REQUEST_URI'];
	else if(isset($_SERVER['SCRIPT_NAME']))
		$uri = $_SERVER['SCRIPT_NAME'];
	else
		$uri = $_SERVER['PHP_SELF'];

	if (isset($_SERVER['SERVER_NAME']))
		$uri = $_SERVER['SERVER_NAME'] . $uri . 'index.php';

However, the uri that this generates is of the form:

http://stevenmbooth.com/bbpress/index.php

Which causes repermalink to create, once again, an endless redirection loop.

More work clearly needs to be done to handle SunOS/Solaris environments, and any system that does not properly supply REQUEST_URI.

(This is 1.0 code by the way. I'm not sure which RC it is (if you tell me where to look, I can tell you) but I think it's RC3.)

Change History (18)

comment:1 follow-ups: sambauers5 years ago

  • Milestone changed from 1.0 to 1.5

We do some re-writing of REQUEST_URI already in bb-load.php ( http://trac.bbpress.org/browser/trunk/bb-load.php#L69 ) Although that is targeted at IIS.

What does the call to bb_get_location() output inside bb_repermalink() on each page? Does it look correct?

I would think that Sun support would be fairly important to bbPress.

As far as I know, you are the first to report any usage on SunOS.

comment:2 follow-ups: SteveBooth5 years ago

I have a further question. Here is the beginning of bb_repermalink:

function bb_repermalink() {
	global $page;
	$location = bb_get_location();
	$uri = $_SERVER['REQUEST_URI'];
	if ( isset($_GET['id']) )
		$id = $_GET['id'];
	else
		$id = bb_get_path();
	$_original_id = $id;

	do_action( 'pre_permalink', $id );

	$id = apply_filters( 'bb_repermalink', $id );

	switch ($location) {
		case 'front-page':
			$path = null;
			$querystring = null;
			if ($page > 1) {
				if (bb_get_option( 'mod_rewrite' )) {
					$path = 'page/' . $page;
				} else {
					$querystring = array('page' => $page);
				}
			}
			$permalink = bb_get_uri($path, $querystring, BB_URI_CONTEXT_HEADER);
			$issue_404 = true;
			break;

I'm particularly concerned with the 'if ($page >1)' in the 'front-page' case. Can someone please tell me where the $page variable is initialized in the prior code? Because as it stands, to my eye, it will always be zero.

comment:3 in reply to: ↑ 1 ; follow-ups: SteveBooth5 years ago

Replying to sambauers:

We do some re-writing of REQUEST_URI already in bb-load.php ( http://trac.bbpress.org/browser/trunk/bb-load.php#L69 ) Although that is targeted at IIS.

What does the call to bb_get_location() output inside bb_repermalink() on each page? Does it look correct?

I would think that Sun support would be fairly important to bbPress.

As far as I know, you are the first to report any usage on SunOS.

$location is set at the top to 'front-page'.

comment:4 in reply to: ↑ 3 SteveBooth5 years ago

$location is set at the top to 'front-page'.

(and that seems correct since we are just browsing to the root of bbPress.)

comment:5 in reply to: ↑ 1 ; follow-up: SteveBooth5 years ago

Replying to sambauers:

We do some re-writing of REQUEST_URI already in bb-load.php ( http://trac.bbpress.org/browser/trunk/bb-load.php#L69 ) Although that is targeted at IIS.

Yes. This seems the correct place to handle SunOS inconsistencies. May I ask, what exactly is the uri construct that should be contained in REQUEST URI? Is it the entire uri from the original page invocation? (I'm trying to figure out what the proper SunOS code should be to add here.)

comment:6 in reply to: ↑ 2 ; follow-up: SteveBooth5 years ago

Replying to SteveBooth:

case 'front-page':

...

$issue_404 = true;
break;

In fact, is it really true that ALL front-page references will generate 404 errors?!

comment:7 in reply to: ↑ 2 sambauers5 years ago

Replying to SteveBooth:

I'm particularly concerned with the 'if ($page >1)' in the 'front-page' case. Can someone please tell me where the $page variable is initialized in the prior code? Because as it stands, to my eye, it will always be zero.

$page is a global value set in bb-settings.php

comment:8 in reply to: ↑ 3 sambauers5 years ago

Replying to SteveBooth:

$location is set at the top to 'front-page'.

Sounds right.

comment:9 in reply to: ↑ 5 sambauers5 years ago

Replying to SteveBooth:

May I ask, what exactly is the uri construct that should be contained in REQUEST URI?

It's the full URL including protocol (http), domain, path and querystring.

comment:10 in reply to: ↑ 6 sambauers5 years ago

Replying to SteveBooth:

In fact, is it really true that ALL front-page references will generate 404 errors?!

No : )

This means that this type of page can (when necessary) issue a 404 instead of redirecting to the front page.

comment:11 SteveBooth5 years ago

Thanks for all your responses, Sam. I'm going to start by updating the code in bb-load.php to properly set up REQUEST_URI. Then I'll try to figure out what is going on in bb_repermalink.

comment:12 SteveBooth5 years ago

Grrr. My stupid server returns 'ConcentricHost-Ashurbanipal/1.8 (Concentric(R))' for $_SERVERSERVER_SOFTWARE?. I need to find a better system variable.

comment:13 SteveBooth5 years ago

Okay. I inserted the following code into bb_load:

	// On some SunOS/Solarix systems, we need to construct the path from 
	// the SERVER_NAME and the SCRIPT_NAME:
	if ( !isset($_SERVER['PATH_INFO']) && 
	      isset($_SERVER['SERVER_NAME']) &&
	      isset($_SERVER['SCRIPT_NAME']) ) {
		$_SERVER['PATH_INFO'] = 'http://' . $_SERVER['SERVER_NAME'] . $_SERVER['SCRIPT_NAME'];
		$_SERVER['REQUEST_URI'] = $_SERVER['PATH_INFO'];
	}


The contents of REQUEST_URI at the end of bb_load was:

     http://www.stevenmbooth.com/bbpress/index.php

And b_repermalink still generated a 404.

comment:14 SteveBooth5 years ago

Okay. I'm sorry, this makes no sense at all to me. I don't understand what bb_repermalink is doing with a perfetly normal url. When the user browses to the bbPress root, the first thing that is done is call repermalink. With the above code in place, the exactly correct uri is placed in REQUEST_URI. $page is set to 1 when the routine is called, and the location is 'front-page'. This is a PARAMETERLESS uri; there is no question-mark anywhere in the uri. As a result, the $querystring is empty, as it should be, and there are no $ars, which I believe is correct.

$permalink is correctly set (i think) to the root path minus the .php file, but after extracting the domain and cleaning up the uri, bb_permalink does this BIZZARE test wherein it's compareing $check (which is null) and $uri, and generating a 404 as a result.

SO... here's my question. If...

$domain is stevenmbooth.com and
$permalink is http://stevenmbooth.com/bbpress/

why in the world would the following replace be correct:

	$check = preg_replace( 
		'|^.*' . trim($domain, ' /' ) . '|',
		 '', 
		$permalink, 
		1
	 );

Because that is what is creating a null $check, and that is what is causing the 404 on a perfectly good uri.

comment:15 SteveBooth5 years ago

Okay. I give up. I've been staring at the bb_repermalink code all day and gone through all the RegEx expressions, and frankly, it's just a mass of confusion, what it's trying to do. I have no knowledge of the objectives or goals for this module, or how it's supposed to fit into the system. Ive tried maybe twenty different fixes, all of which generate either a 404, or cause bbPress to go into a redirect loop.

I need help at this point. Any direction would greatly be appreciated. I have re-enabled the full debugging list on http://stevenmbooth.com/bbpress. Perhaps I can return to this later.

This is very discouraging -- being unable to get bbPress to work after it's supposed to be a trivial install.

<sigh>

comment:16 GautamGupta4 years ago

  • Version changed from 1.0-rc-1 to 1.0.2

comment:17 johnjamesjacoby3 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

Ticket has gone cold and the site listed above is dead, so closing as wontfix since there are no other documented instances of this occurring.

comment:18 johnjamesjacoby3 years ago

  • Milestone changed from Future Release to 1.0.3
  • Version 1.0.2 deleted
Note: See TracTickets for help on using tickets.