#383 404 Error after saving reservation with Windows 7 IE browser

[Anonymous]

Hello,

I've found a bug when using Windows 7 with Internet Explorer. After saving a new meeting it was redirected to a 404 page.
After same research I found out, that the "if" in the file edit_entry_handler.php (on line 580) made the error come up. This if resolved to false and the else part returned an invalid url.
I've commented this if out and now everything works as excepted.

It would be nice if this error could be corrected in a futur release.

Greetings, André

[Campbell Morrison]

Which version of MRBS are you looking at? I can't see an if else at line 580 in 1.6.1.

[Campbell Morrison]

OK, sorry, I missed the else. I assume you mean the one at 579 in 1.6.1.

[Campbell Morrison]

I couldn't reproduce the problem, but I've rewritten the code anyway. See 6960bb. The new section of code is below. Maybe you could try it on your system and see if it fixes the problem? If it doesn't fix the problem, maybe you could post the $returl that is causing the problem (having removed any domain names etc.).

// First get the return URL basename, having stripped off the old query string
//   (1) It's possible that $returl could be empty, for example if edit_entry.php had been called
//       direct, perhaps if the user has it set as a bookmark
//   (2) Avoid an endless loop.   It shouldn't happen, but just in case ...
//   (3) If you've come from search, you probably don't want to go back there (and if you did we'd
//       have to preserve the search parameter in the query string)
if (isset($returl) && ($returl !== ''))
{
  $returl = parse_url($returl, PHP_URL_PATH);
  if ($returl !== false)
  {
    $returl = explode('/', $returl);
    $returl = end($returl);
  }
}

if (empty($returl) || 
    in_array($returl, array('edit_entry.php',
                            'edit_entry_handler.php',
                            'search.php')))
{
  switch ($default_view)
  {
    case 'month':
      $returl = 'month.php';
      break;
    case 'week':
      $returl = 'week.php';
      break;
    default:
      $returl = 'day.php';
      break;
  }
}

[Anonymous]

Hello,

unfortunately it has not resolved the problem.
The returl has the following value:
/mrbs/edit_entry.php?area=1&room=11&hour=10&minute=0&year=2017&month=03&day=27

In addition I found out, that the problem is due to the fact, that I use an iframe to include the MRBS.
When removing the iframe the error does not occur.

[Campbell Morrison]

OK, thanks, that's useful information. I'll see if I can reproduce it using an iframe.

[Campbell Morrison]

I did manage to reproduce it once, but not again. However searching on the net I think the problem is that IE8 doesn't like relative URLs. Could you try it again with the following piece of code underneath the section I gave you above:

// Turn the location into an absolute location, to keep IE8 happy.
$scheme = (isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS'] !== 'off')) ? 'https' : 'http';
$host = $HTTP_HOST;
$dir = dirname($PHP_SELF);
$returl = "$scheme://$host$dir/$returl";

I have committed this change to the default branch in ebe0e8.

[Campbell Morrison]

I've now reverted this change in the default branch as it didn't solve the problem.

[Campbell Morrison]

If this fixes the problem then I think there are a number of other places in the code where you'll meet the same problem. For example try clicking on the "Edit" icon to edit an area's settings on the "Rooms" page.

[Anonymous]

Unfortunately that did not fix the problem either.
The Internet Explorer version I use is 11.0.9600.18499 so it is not IE8 related.
The "Edit" from a room does work like suspected and I did not find anything else than is not working. Also the reservation is executed i.e. when I can see the reservation created it's only that I am redirected to the wrong site after the creation of the reservation.

[Campbell Morrison]

Does it work with other browsers?

[Anonymous]

I've tried with Firefox and there it is working.

[Campbell Morrison]

The only other suggestion I've found on the net is that there's something weird going on with caching. Can you try adding the following lines at the top of edit_entry_handler.php, just after the 'require' statements:

header("Pragma: no-cache");                          // HTTP 1.0
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");    // Date in the past

[Anonymous]

That didn't work neither :-(

[Campbell Morrison]

I'm not quite sure what to do next. If you were willing to give me (via private message) a link to your system and a user login then I might be able to get some more information.

[Anonymous]

No, that's not possible the MRBS is running in the closed environment of our enterprise.
Well I think I stick with my solution to comment the "IF" out until all our Windows 7 machines are upgraded to Windows 10.

Nevertheless, thanks for your help

[Campbell Morrison]

OK, does it not happen on Windows 10?

[Campbell Morrison]

One thing that might give me a clue is if you could send me a private message with the value of $returl just before that if block.

[Anonymous]

On Windows 10 there is no problem.
The returl I gave you is the one how it is before the block.

[Campbell Morrison]

I've managed to reproduce this one more time and got some information from the 404 page. My suspicion is that in some circumstances the server variable 'HTTP_REFERER' is being taken from the src attribute of the iframe element. In my case I had the src attribute just pointing to the directory that contained MRBS, eg src="foo/bar/mrbs/".

Unfortunately I can't work out how to reproduce the problem reliably. However, if my suspicion is correct, then changing the src attribute to "foo/bar/mrbs/index.php" might solve the problem.

[Campbell Morrison]

Sorry, I meant "foo/bar/mrbs/index.php", ie add "index.php". I have edited the post above to correct it.

[Anonymous]

This looked very promising but unfortunately it didn't helped.
For me the 404 page is shown every time I try it's not randomly that I get it.