Summary | Free/Busy URL - fb.php broken |
Queue | Kronolith |
Queue Version | HEAD |
Type | Bug |
State | Resolved |
Priority | 2. Medium |
Owners | |
Requester | graeme (at) graemef (dot) net |
Created | 03/21/2005 (7418 days ago) |
Due | |
Updated | 04/01/2016 (3389 days ago) |
Assigned | |
Resolved | 03/22/2005 (7417 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
State ⇒ Resolved
OK... so now we have to work out why my webserver is doing this - I
suspect that it may be the same for the other people with the same
issue. Looks like I've discovered some "corner case".
Although you marked the bug as "resolved"...
This is an fairly normal Apache installation, with PHP running under a
local user directory as a CGI using "ForceType" to run Horde.
Everything else works except this!
State ⇒ Not A Bug
considers PATH_INFO. PATH_INFO is used to provide simpler URLs for the
majority of people whose webservers support it correctly.
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ Free/Busy URL - fb.php broken
Queue ⇒ Kronolith
New Attachment: fb.php.patch
2005, use of the freebusyurl in kronolith 2.1-cvs (HEAD branch) is
broken when attempting to:
1. View Free/busy URL directly from a browser.
2. Check other users' availability when adding them to a new (or
existing) event.
As far as I can tell, kronlolith/fb.php is broken as it tries to use
the PATH_INFO environment variable to determine the calendar name it
is using:
// Determine the username to show free/busy time for.
if (!empty($_SERVER['PATH_INFO'])) {
$cal = basename($_SERVER['PATH_INFO']);
} else {
$cal = Util::getFormData('c');
if (is_array($cal)) {
$cal = implode('|', $cal);
}
}
In this logic, if $_SERVER['PATH_INFO'] is set (regardless of value)
then the query option "c=username" passed in the URI is ignored.
In my case, this then produces a calendar name of "fb.php" which,
unless I have a *very* odd set of usernames :) is not going to be
valid. I can't see why this environment variable is used at all; maybe
someone could enlighten me on that one...
In any case, I made a change to fb.php (patch attached) which ignores
it. The patch needs better error condition handling as it's possible
to pass an invalid username which will then return a bogus empty
response, but it's fixed it for me.
Is this valid, or just rubbish?