HFS Icons through an Apache Reverse Proxy

[ELEVENNNN]

Since your running a reverse proxy with apache im sure you have some unix roots but just in case, what I mean is.

in your template instead of /template/icons/myicon.gif
you put
http://myserver.com/template/icons/myicon.gif (Appears external but it works)

Let everyone know your sucess/failure.
-Kurt

[Unknown8063]

OMG I cannot believe I didn't see this thread earlier   Probably because I don't lurk in the router and ports forum.

I also run HFS behind a reverse proxy and noted the missing 16x16 icon images.  It's been bugging me for awhile but recently I just switched to Terayon because it doesn't use the icon images (which evidently is the only thing broken). Has there been a solution to this issue?

While at first convincing, I do not think the theory that the tilde conflicts with user home folders is accurate.  I can still access /~upload right on the root without problems.  Additionally, if I attempt to access the images directly from the address bar HFS fires off a 404 instead of Apache so it is clearly going through the reverse proxy correctly.

[rejetto]

is actually HFS giving the 404 ?

disable "log what - only served requests"
enable "log what - replies"
enable "log what - requests"
then access the images directly and see what the log says

[Unknown8063]

I ran the test as described using build 144 and received the following:

11/21/2007 3:47:53 PM 5.x.x.x:53041 Requested GET /~img8
11/21/2007 3:47:53 PM 5.x.x.x:53041 Not served: 404 - Not found
11/21/2007 3:47:53 PM 5.x.x.x:53042 Requested GET /~style.css
11/21/2007 3:47:53 PM 5.x.x.x:53042 Served 570 B

[rejetto]

hfs is replying 404 to /~img8 ?
how could it be?
can you also enable dump request?
or even better post an hex dump of the request using a sniffer.

[Mars]

it seems that url line like ~img8 works only if you are in root

http://server/~command      works good

http://server/folder/~command  don't works : page introuvable

only ~login works anywhere

This is bound to the way is tested the url for the commands preceded of ~

[rejetto]

yes mars, this is the wanted behaviour.
i don't see how this can be related to their problem.

[Unknown8063]

Attached is the log file using the requests dump, also on a direct access attempt of /~img8.

Rejetto, if this doesn't help I ca do the hex dump too.  Thanks for the help!

[rejetto]

ok now i have a clue for further investigations, thank you

[rejetto]

Thank you 8063, the bug is finally fixed in next build #146
it was actually a bug in HFS

[Unknown8063]

Thank you Rejetto! I can confirm that the bug is fixed.

[KlausR]

The issue lies with a problem with Apache proxy not translating the ~ character correctly. The ~ is urlencoded which is not compatible with HFS. Upgrade to a version of Apache greater than 2.2.6. At the time of this posting the current version is 2.2.8

[rejetto]

as stated above, it was an HFS bug, and it has been fixed

[KlausR]

Please see attached for the log file. The log file was generated with HFS 2.2d and with Apache 2.2.0 as a reverse proxy.

The log file shows the log in page.  Have a look at how ~img27 is translated.

The problems went away after upgrading to 2.2.8.

See change log in Apache for 2.2.6:
http://www.apache.org/dist/httpd/CHANGES_2.2
*) mod_proxy: don't URLencode tilde in path component
    PR 38448 [Stijn Hoop <stijn sandcat.nl>]

Thanks for a great product.

[rejetto]

thanks for reporting klausr.
actually, the encoding by apache was not due, and it is better it now doesn't.
while such encoding is not advisable, it is allowed by the protocol (i think), and so i considered it an HFS bug, to handle it incorrectly.

the result is that HFS 2.3 handles such problematic request successfully.
sadly, i forgot to include this fix in last 2.2 release. And i guess i won't, since i hope 2.3 will go stable soon.