Forum

I've setup Hiawatha as a reverse proxy only in front of my Apache server. This is working great.

# CACHE
CacheSize = 32
CacheMaxFilesize = 1024
CacheRProxyExtensions = js, css, jpg, jpeg, png, ico, gif

# REVERSE PROXY
ReverseProxy .* http://127.0.0.1 300

However css or js files like style.css?ver=1.8.1 are not being cached.

Here are two examples. Both are requested in one pageload.

Verzoek-URL:http://example.com/wp-content/themes/blaskan-child/style.css?ver=3.5.1
Verzoekmethode:GET
Statuscode:200 OK
Vraagkoptekstentoon bron
Accept:text/css,*/*;q=0.1
Referer:http://example.com/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2
Parameters voor zoektekenreekstoon URL gecodeerd
ver:3.5.1
Antwoordkoptekstentoon bron
Accept-Ranges:bytes
Connection:close
Content-Length:695
Content-Type:text/css
Date:Thu, 28 Feb 2013 13:04:04 GMT
Etag:"65ec-2b7-4d5ab7a21c500"
Last-Modified:Thu, 14 Feb 2013 08:59:32 GMT
Server:Apache


Verzoek-URL:http://example.com/wp-content/themes/blaskan/style.css
Verzoekmethode:GET
Statuscode:200 OK
Vraagkoptekstentoon bron
Accept:text/css,*/*;q=0.1
Referer:http://example.com/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2
Antwoordkoptekstentoon bron
Accept-Ranges:bytes, bytes
Connection:keep-alive, close
Content-Length:37967
Content-Type:text/css
Date:Thu, 28 Feb 2013 13:04:04 GMT, Thu, 28 Feb 2013 13:03:55 GMT
Etag:"664d-944f-4d49174840c40"
Last-Modified:Thu, 31 Jan 2013 08:31:37 GMT
Server:Hiawatha v8.8, Apache


The first one is served via Apache, the second one (without ?ver=3.5.1) is served via Hiawatha.

Both files should be in the cache because I did a full pageload with caching off in the browser a few seconds before.
This is also true voor JS files with the same ?ver=3.5.1 behind the extension.

Hiawatha version: 8.8
Operating System: Debian 6.0

You can check if they are in Hiawatha's cache via Tomahawk (see Hiawatha manpage).

The ?ver= files are not in the cache of Hiawatha. They also show up in the apache logs. The css files without ?ver= do not show up in the apache log.

One strange thing though. When I login to tomahawk and having performed some commands like show cache, Hiawatha totally dies. I must restart it. Tomahaak does not respond and also the sites do not load any more.

Please, follow these instructions.

What happens. When I start Hiawatha as a daemon with service start hiawatha and login to tomahawk all goes well. I can run commands etc.
At the moment I load a page with my browser hiawatha crashes.

So I've followed your valgrind instruction but fore some reason hiawatha does not crash with the same actions performed.
Only when start via service start hiawatha it crashes when logged in on tomahawk and loading a page.

Anyway here is the output of valgrind:

==18163== Memcheck, a memory error detector
==18163== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==18163== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==18163== Command: hiawatha -d
==18163== 
==18163== Invalid write of size 2
==18163==    at 0x80553D3: run_server (hiawatha.c:1931)
==18163==    by 0x805591C: main (hiawatha.c:2086)
==18163==  Address 0x43c1334 is 0 bytes after a block of size 20 alloc'd
==18163==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==18163==    by 0x805534E: run_server (hiawatha.c:1894)
==18163==    by 0x805591C: main (hiawatha.c:2086)
==18163== 
==18163== Syscall param poll(ufds.events) points to unaddressable byte(s)
==18163==    at 0x42FC9A6: poll (poll.c:87)
==18163==    by 0x8055416: run_server (hiawatha.c:1939)
==18163==    by 0x805591C: main (hiawatha.c:2086)
==18163==  Address 0x43c1334 is 0 bytes after a block of size 20 alloc'd
==18163==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==18163==    by 0x805534E: run_server (hiawatha.c:1894)
==18163==    by 0x805591C: main (hiawatha.c:2086)
==18163== 
==18163== Syscall param poll(ufds.reventss) points to unaddressable byte(s)
==18163==    at 0x42FC9A6: poll (poll.c:87)
==18163==    by 0x8055416: run_server (hiawatha.c:1939)
==18163==    by 0x805591C: main (hiawatha.c:2086)
==18163==  Address 0x43c1336 is 2 bytes after a block of size 20 alloc'd
==18163==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==18163==    by 0x805534E: run_server (hiawatha.c:1894)
==18163==    by 0x805591C: main (hiawatha.c:2086)
==18163== 
==18163== 
==18163== HEAP SUMMARY:
==18163==     in use at exit: 14,118 bytes in 470 blocks
==18163==   total heap usage: 1,725 allocs, 1,255 frees, 444,633 bytes allocated
==18163== 
==18163== 160 (40 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 89 of 107
==18163==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==18163==    by 0x431ADD3: nss_parse_service_list (nsswitch.c:622)
==18163==    by 0x431B516: __nss_database_lookup (nsswitch.c:164)
==18163==    by 0x47B6EAB: ???
==18163==    by 0x47B7F84: ???
==18163==    by 0x42D4334: getpwnam_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253)
==18163==    by 0x42D3D9E: getpwnam (getXXbyYY.c:117)
==18163==    by 0x806973E: parse_userid (userconfig.c:36)
==18163==    by 0x8062B99: read_main_configfile (serverconfig.c:955)
==18163==    by 0x80549D9: run_server (hiawatha.c:1541)
==18163==    by 0x805591C: main (hiawatha.c:2086)
==18163== 
==18163== 160 (40 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 90 of 107
==18163==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==18163==    by 0x431ADD3: nss_parse_service_list (nsswitch.c:622)
==18163==    by 0x431B516: __nss_database_lookup (nsswitch.c:164)
==18163==    by 0x47B5F2B: ???
==18163==    by 0x47B6E34: ???
==18163==    by 0x431BC21: __nss_getent_r (getnssent_r.c:171)
==18163==    by 0x42D2C95: getgrent_r@@GLIBC_2.1.2 (getXXent_r.c:162)
==18163==    by 0x431B81A: __nss_getent (getnssent.c:38)
==18163==    by 0x42D2679: getgrent (getXXent.c:84)
==18163==    by 0x80694D4: lookup_group_ids (userconfig.c:144)
==18163==    by 0x8062CF8: read_main_configfile (serverconfig.c:961)
==18163==    by 0x80549D9: run_server (hiawatha.c:1541)
==18163== 
==18163== 6,221 (264 direct, 5,957 indirect) bytes in 1 blocks are definitely lost in loss record 107 of 107
==18163==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==18163==    by 0x805F972: default_config (serverconfig.c:252)
==18163==    by 0x80549A9: run_server (hiawatha.c:1534)
==18163==    by 0x805591C: main (hiawatha.c:2086)
==18163== 
==18163== LEAK SUMMARY:
==18163==    definitely lost: 344 bytes in 3 blocks
==18163==    indirectly lost: 6,197 bytes in 335 blocks
==18163==      possibly lost: 0 bytes in 0 blocks
==18163==    still reachable: 7,577 bytes in 132 blocks
==18163==         suppressed: 0 bytes in 0 blocks
==18163== Reachable blocks (those to which a pointer was found) are not shown.
==18163== To see them, rerun with: --leak-check=full --show-reachable=yes
==18163== 
==18163== For counts of detected and suppressed errors, rerun with: -v
==18163== ERROR SUMMARY: 258 errors from 6 contexts (suppressed: 39 from 10)

Weird. I installed a Debian 6.0 VM and tested Hiawatha, but everything worked just fine. No crash no matter what I do.

I used the 64-bit version. What did you use?

32 bit.

It's a kvm vps with 512MB memory.
Hiawatha runs fine serving pages no crashes. Only when telnetted to tomahawk and reloading a page.

Good thing is that I was able to reproduce the crash (indeed on 32-bit Debian). Bad thing is that I still don't know why it crashes. It has something to do with the poll() function. A workaround for me is to increase MAX_ADMIN_CONNECTIONS in hiawatha.c at line 83 from 3 to 4.

Got it!!! The bug is in hiawatha.c at line 1894. Change "sizeof(struct pollfd*)" to "sizeof(struct pollfd)" and the crashes should no longer occur.

Ok. I'll try it.

Luckily it's a minor bug because I don't use Tomahawk a lot. But is nice to be fixed for other customers to.

Do you have any idea why the ?ver=1.8.1 files won't cache?

No, not yet. That's next on my todo-list.

Tnx.

I've changed my setup temporary a bit. Instead of forwarding all requests with reverseproxy, I added a virtual host for that webstie.
The document root is the same as Apache. Added a reverse proxy within the virtual host to forward .php and slugs to apache.
This works.

After that I setup a urltoolkit and set a 'expire' on all js, css and jpg files.

Gues what. The jpgs, js and css files get a Expire header. But the style.css?ver=1.8.1 do not get a Expire header .

So it looks likes it is not just with the reverseproxy extensions.

Hope this info helps.

Found the bug. Will be fixed in the next release.

Great. Is it easy to fix / can you supply me a patch?

No, but I can give you a preview of the 8.9 release. Consider this one alpha!
http://www.leisink.net/hiawatha-8.9.tar.gz