6.0.0-git
2019-04-22

[#1339] HTTP_HOST
Summary HTTP_HOST
Queue Horde Base
Queue Version 3.0.2
Type Bug
State Not A Bug
Priority 2. Medium
Owners
Requester john (at) oztralis (dot) com (dot) au
Created 2005-02-09 (5185 days ago)
Due
Updated 2005-02-10 (5184 days ago)
Assigned 2005-02-09 (5185 days ago)
Resolved 2005-02-09 (5185 days ago)
Milestone
Patch No

History
2005-02-10 00:04:48 john (at) oztralis (dot) com (dot) au Comment #8 Reply to this comment
Exactly, which means you're suggesting that I should have two 
identical entries in servers.php, one that has preferred = 'domain' 
and one that has preferred='domain:80'

that doesn't really seem right to me, since essentially they're the same....




2005-02-09 23:35:35 Jan Schneider Comment #7 Reply to this comment
IMP::isPreferredServer() compares HTTP_HOST (among other server 
variables) with the 'preferred' setting from servers.php. So again 
it's a configuration issue.



And I really have no idea why you are referring to the radius auth 
driver, that btw. uses HTTP_HOST only if you didn't configure a server 
name. Again.
2005-02-09 22:51:14 john (at) oztralis (dot) com (dot) au Comment #6 Reply to this comment
I wrote: 'Likewise, in imp/lib/IMP.php in function isPreferredServer() 
the HTTP_HOST header is used to determine the mailserver to use, and 
in lib/Horde/Auth/radius.php in function _setParams() it is used to 
set the NAS identifier.'



Closing the bug while it persists? I'm confused!

Would you mind explaining why you don't believe this to be a bug?


2005-02-09 22:45:49 john (at) oztralis (dot) com (dot) au Comment #5 Reply to this comment
right,. but it still means I have to change the IMP.php file, which 
may get overwritten by updates, which seems suboptimal.



btw,.... with regards to the missing chunk header, I've found that 
setting the following apache directive stops that from happening,. but 
I'm not sure of the implications:



BrowserMatch ".*" downgrade-1.0 force-response-1.0



Kind Regards,



John
2005-02-09 22:34:04 Jan Schneider Comment #4
State ⇒ Not A Bug
Reply to this comment
You said it in your first sentence: it's an example. If it doesn't 
work for you, use some code that does.
2005-02-09 21:42:05 john (at) oztralis (dot) com (dot) au Comment #3 Reply to this comment
in config/hooks.php is an example on how to configure Horde/IMP for 
virtual hosts.

it does $vdomain = getenv('HTTP_HOST'); which means the username used 
to authenticate agains imap becomes 'user@domain:80' if the host 
header includes the port number, EVEN if the port number is 80.



Likewise, in imp/lib/IMP.php in function isPreferredServer() the 
HTTP_HOST header is used to determine the mailserver to use, and in 
lib/Horde/Auth/radius.php in function _setParams() it is used to set 
the NAS identifier.



Under normal circumstances I wouldn't think this would present a 
problem since the host header normally doesn't contain a :port number 
when running on port 80, but reverse proxies such as Pound 
(http://apsis.ch/pound) adds the port number explicitly.



You can test this behaviour by adding :80 to the url in your browser.



I have also noticed another problem, which I believe to be related to 
Horde/IMP. since I run other php based solutions on the same backend 
servers and have only ever seen this happen with Horde/IMP...:



On occasion, a http request will fail, and either the navigation 
frame, or the main frame will fail to load.



using lwp-request to investigate the problem, I get this:

500 EOF when chunk header expected.





Kind Regards,



John Hansen
2005-02-09 13:59:46 Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
Can you please tell us what you are talking about? What does the 
HTTP_HOST have to do with authentication?
2005-02-09 10:51:20 john (at) oztralis (dot) com (dot) au Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ HTTP_HOST
Queue ⇒ Horde Base
Reply to this comment
when $_SERVER['HTTP_HOST'] contains a port number, authentication 
fails against imap accounts using the format ${user}@${HTTP_HOST}



I believe HTTP_HOST should _always_ be parsed for host:port and only 
use the host part....



This becomes a problem when using reverse proxies, which always add 
the port number explicitly, even when connecting to port 80, eg:



GET / HTTP/1.1

Host: hostname:80



Kind Regards,



John

Saved Queries