[Wifidog] incorporate_libhttpd branch merged
webmaster at topfx.com
Wed Mar 17 09:37:30 EST 2004
-----BEGIN PGP SIGNED MESSAGE-----
Philippe April wrote:
> I tested it and I can't seem to make it work right now.
> However, I found what's not working and it's simple.
> The auth page on the auth server is (configurable)
> authserver.com/wifidog/auth and the login page is
> The page my http functions were answering to were just /auth (not
> /wifidog/auth) but your hooks are now handling /wifidog/auth/.
> So basically, the central server code (PHP) has to know the path wifidog
> will answer to, and same for the reverse (auth forwarding to gw has to
> know the path on the gw).
> I suppose we could keep the central server at /wifidog/auth and
> /wifidog/login, since the server might handle other things other than
> wifidog stuff. We could leave the admin of the central server decide that.
> But for the gateway part, I think we should make it just /auth, /about,
> and the rest goes to 404 (which is supposed to be redirected to the
> central server...?)
> What do you guys think? Ideas?
The reason I changed it from /auth to /wifidog/auth on the gateway side is:
1. libhttpd doesn't allow for custom 404 pages. So what I did was tell
it capture /* and do the re-direct to the central server. I'm
contemplating hacking libhttpd to allow for a custom 404 handler.
2. Because of the above, /* was taking preference over /auth. In essence
it was no longer possible to reach the "auth" hook since the catch-all
was more authoritative. That is why I had to move it 1 level deeper,
3. If someone happens to be going to http://www.anywebsite.com/auth we
don't want confusion or the auth handler to kick in when it shouldn't have.
I think the ideal solution is to hack libhttpd to add custom 404
handler, that way we support initial requests that are 2+ levels deep
(www.blah.com/firstlevel/secondlevel/filename.html). But I think we
should keep the handlers as /wifidog/FOO or /wifidog_handler/FOO for
> Other than that, I think libhttpd makes it super clean. If it's possible
> to use it to forge clean HTTP GET requests and parse the responses, it'd
> be good to use it for that too!
No you can't. For that we'd need libcurl or something similar.
At the meeting tonight I'll propose we DON'T use HTTP when the gateway
is talking to the central server. A much simpler text protocol without
all the HTTP hoopla would be much simpler to code gateway-side.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
Wifidog mailing list
Wifidog at isf.waglo.com
More information about the Wifidog